高性能的MySQL(4)Schema设计

一、设计中的陷阱

1、太多的列

MySQL的存储引擎API工作时需要在服务器层和存储引擎层之间通过行缓冲格式拷贝数据,然后在服务器层将缓冲内容解码为各个列。这是一个代价很高的操作,转换的代价依赖于列的数量,列太多的话,转换代价就会很高。

2、太多的关联

一个粗略的经验法则,如果希望查询和并发行好,单个查询不要超过10个表的关联。

3、过度的枚举

修改一个枚举列的值时,需要alter table的阻塞操作,代价很高。

4、避免不可能的值

CREATE TABLE date_test(
    dt DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00');

二、混用范式和反范式

最常见的反范式数据的方法是复制或者缓存,在不同的表中存储相同的特定列。缓存衍生值,比方说某个帖子的评论总数。混用的目的是在关联查询和增删改操作上做一个性能的折中考虑。

三、缓存表和汇总表

缓存表来存储那些某个主表上的一部分列数据,用来提供高效的查询操作。

汇总表保存的是使用GROUP BY语句聚合数据的表。

建立这些表是为了减少在主表上因为某些查询需要加很多特殊的索引。

当重建汇总表或缓存表时,通常需要保证数据在操作时仍然可用。这就需要通过使用“影子表”。

drop table if exists my_summary_new,my_summary_old;
create table my_summary_new like my_summay;
#导入数据
rename table my_summary to my_summary_old,my_summary_new to my_summary;

四、计数器

如果在表中保存计数器,在更新计数器时可能碰到并发问题,所以创建一张独立的表存储计数器通常是个好主意。

假设有一个计数器表,只有一行数据,记录网站的点击次数

网站的每次点击都会导致对计数器更新

update hit_counter set cnt = cnt + 1;

问题在于,对于任何想要更新这一行的事务来说,这条记录会有全局的写锁,这会使事务只能串行执行。要获得更高的并发行,可以将计数器保存在多行中,每次随机选择一个行更新。

create table hit_counter(

   id tinyint unsigned not null primary key,

   cnt int unsigned not null

) engine = innodb;

然后预先增加100行数据,当更新的时候随机选择一条记录来更新

update hit_counter set cnt=cnt+1 where id= rand()*100;

这样的统计结果就变成了

select sum(cnt) from hit_counter;

一个常见的需求是每隔一段时间开始一个新的计数器,这个时候需要简单的修改一下表的设计

以上是小编为您精心准备的的内容,在的博客、问答、公众号、人物、课程等栏目也有的相关内容,欢迎继续使用右上角搜索按钮进行搜索数据
, 缓存
, 更新
, 范式
, 计数器
一个
高性能mysql第4版、高性能mysql第4版 pdf、高性能mysql第4版百度、mysql schema、mysql schema是什么,以便于您获取更多的相关知识。

时间: 2024-08-29 11:35:15

高性能的MySQL(4)Schema设计的相关文章

MySQL主键设计

原文:MySQL主键设计 [TOC] 在项目过程中遇到一个看似极为基础的问题,但是在深入思考后还是引出了不少问题,觉得有必要把这一学习过程进行记录. MySQL主键设计原则 MySQL主键应当是对用户没有意义的. MySQL主键应该是单列的,以便提高连接和筛选操作的效率 永远也不要更新MySQL主键 MySQL主键不应包含动态变化的数据,如时间戳.创建时间列.修改时间列等 MySQL主键应当有计算机自动生成. 主键设计的常用方案 自增ID 优点: 1.数据库自动编号,速度快,而且是增量增长,聚集

【转载】低成本和高性能的MySQL云数据库的实现淘宝 MySQL

低成本和高性能的MySQL云数据库的实现 作者: 鸣嵩/曹伟(集团技术专家) 本文刊登于<程序员>杂志2012年12期上,转载请注明         UMP(Unified MySQL Platform)系统是淘宝核心系统数据库团队开发的低成本和高性能的MySQL云数据方案,关键模块采用Erlang语言实现.系统中包含了controller服务器.proxy服务器.agent服务器.API/Web服务器.日志分析服务器.信息统计服务器等组件,并且依赖于Mnesia.LVS.RabbitMQ.Z

php+mysql商城数据库设计问题

问题描述 php+mysql商城数据库设计问题 需要为每个用户都建立一张表来存储他的购买记录吗,这样至少会有上千张表. 如果用一张表来存放所有用户的购买记录那么表又有好多条数据. 到底哪个查找好一点呢? 解决方案 不用的,你在给用户一个商品id,购买商品的id,然后到对应商品库查就可以了.当用户点击购买后就将这个商品的id保存到用户表就可以了 解决方案二: 用用户id以及商品id来生成一个表.或者用mingodb灯nosql数据库,比较好描述这种关系 解决方案三: 肯定是第二种,用一张表来存放所

高性能的MySQL(8)优化服务器配置:并发和负载

当MySQL遇到高并发时,可能会遇到不曾遇到的瓶颈. 一.InnoDB并发配置 InnoDB是为高性能设计的,在最近几年他的提升非常明显,但依然不完美. InnoDB有自己的 "线程调度器"控制线程怎么进入内核访问数据,以及他们在内核中一次可以做哪些事情.最基本的限制并发的方式是使用innodb_thread_concurrency变量,它会限制一次性可以有多少个线程进入内核,0表示不限制. 理论上,下面的公式可以给出一个这样的值 并发值 = CPU数量 * 磁盘数量 * 2 但是在实

高性能的MySQL(8)优化服务器配置:I/O

有一些配置项影响着MySQL怎样同步数据到磁盘以及如何做恢复操作,这写操作对性能影响很大,因为都设计到昂贵的I/O操作,通常保证数据立刻并且一致的写到磁盘是很昂贵的,有的时候不得不冒一点险,延迟持久化到磁盘,来增加并发和减少I/O等待. 一.InnoDB I/O配置 对于常见的应用,InnoDB日志文件大小.InnoDB怎样刷新日志缓冲,以及怎样执行I/O比较重要. a.InnoDB事务日志 InnoDB使用日志来减少提交事务时的开销,日志记录了事务,就无须在每个事务提交时把缓冲池刷新到磁盘中了

高性能的MySQL(6)查询慢与重构查询

只有好的库表结构.合理的索引还不够,我们还需要合理的设计查询,齐头并进,一个不少才能充分发挥MySQL的优势. 一.查询为什么会慢? 每一个查询由一系列的子任务组成,每个子任务都会消耗一定的时间.这个我们在之前的单个查询分析时已经简单介绍了,当然还有额外的因素,比方说包括网络,CPU计算,统计信息,执行计划,锁等待等操作,或者底层引擎在调用内存,CPU操作,I/O操作等上的消耗时间. 优化查询的目的就是减少和消除这些操作所花费的时间. 查询性能低下的最基本原因是访问的数据太多,大部分的性能低下的

高性能的MySQL(5)索引策略-索引案例分析

理解索引最好的办法是结合实例,接下来分析一个例子. 假设要设计一个在线约会网站,用户信息表有很多列,包括国家,地区,城市,性别,眼睛颜色等等.网站必须支持上面的各种组合来搜索用户,包括根据用户的最后在线时间,评分等进行排序的限制. 需要考虑是需要索引来排序还是先检索数据再排序,因为使用索引排序会严格限制索引和查询的设计.如果MySQL使用了某个索引的范围查询,也就无法再使用另一个索引或者是该索引的后续字段进行排序了.接下来一步步讨论: 1.支持多种过滤条件 country列的选择性通常不高,但是

高性能的MySQL(4)数据类型的优化

一.基本原则 1.更小的通常更好 更小的数据类型通常更快,因为占用更少的磁盘.内存和CPU缓存,并且处理时需要的CPU周期也更少. 但是要确保没有低估需要存储的值的范围,因为在schema中的多个地方增加数据类型的范围是个非常耗时的操作. 2.简单就好 例如,整数比字符串操作代价更低,应该用内建类型而不是字符串来存储时间和日期,用整型存储IP. 3.尽量避免NULL 可为NULL的列使用更多的存储空间,需要特殊的处理.特别是可为NULL的列被索引时,每个索引需要额外的字节,在Myisam引擎里甚

在Oracle专家眼中,MySQL sys Schema是怎样一种存在?

作者介绍 杨建荣,DBAplus社群联合发起人.现就职于搜狐畅游,Oracle ACE-A.YEP成员,超7年数据库开发和运维经验,擅长电信数据业务.数据库迁移和性能调优.持Oracle 10G OCP,OCM,MySQL OCP认证,<Oracle DBA工作笔记>作者.   sys Schema的初衷   MySQL的数据字典经历了几个阶段的演进,MySQL4.1 提供了information_schema 数据字典,一些基础元数据可以通过SQL来查询得到. MySQL5.5 提供了per