6.6.数据库优化原则
优化终级奥义
针对百万数量级,放弃在mysql中的join操作,推荐分别根据索引单表取数据,然后在程序里面做join , merge数据。
尽量使用nosql,例如redis , memcached等来缓存热点数据,从而缓解mysql压力。
数据库其他优化原则
总体优化原则
不在数据库做运算,运算务必移至业务层
库命名简洁明确(长度不能超过30个字符)
控制列数量(字段少而精,字段数建议在20以内)
平衡范式与冗余(效率优先﹔往往牺牲范式)
拒绝3B(拒绝大sql语句: big sql、拒绝大事务: big transaction、拒绝大批量:big batch)
字段类优化原则
用好数值类型(用合适的字段类型节约空间)
字符转化为数字(能转化的最好转化,同样节约空间,提高查询性能)
避免使用NULL字段(NULL字段很难查询优化、NULL字段的索引需要额外空间、NULL字段的复合索引无效)
少用text类型(尽量使用varchar代替text字段)
索引类优化原则
合理使用索引(改善查询,减慢更新,索引一定不是越多越好)
字符字段建前缀索引(例如: abckk,dfgkk,fdskk....只要前面3个)
不在索引做列运算(例如: select * from t1 where id+1=10)
innodb主键推荐使用自增列(主键建立聚簇索引,主键不应该被修改,字符串不应该做主键)(理解Innodb的索引保存结构就知道了);不用外键(由程序保证约束)
SQL类优化原则
sql语句尽可能简单(一条sql只能在一个cpu运算,大语句拆小语句,减少锁时间,一条大sql可以堵死整个库)
简单的事务(最好是不要有事务)
避免使用trig/func(不用触发器、函数。客户端程序取而代之)
不用select*(消耗cpu,io,内存,带宽,这种程序不具有扩展性)
OR改写为IN(在字段没有索引的情况下性能差别较大)
OR改写为UNION(索引无效变有效)
使用union all替代union(union有去重开销,例如分表操作explain select name from t3 where idc<=2 union selectname from t3 where idc=3\G)
少用连接join (超过3个join,一般移到业务代码里执行)
分页limit优化(偏移量越大,执行越慢)
结构类优化原则
表范式化原则
范式化是指数据库设计的规范,目前范式化一般是指设计到第三范式。也就是要求数据表中不存在非关键字段对任意候选关键字段的传递函数依赖,则符合第三范式。
反范式化原则
反范式化是指为了查询效率的考虑把原本符合第三范式的表“适当”的增加冗余,以达到优化查询效率的目的,反范式化是一种以空间来换取时间的操作。
垂直拆分原则
1、不常用的字段单独存放到一个表中
2、大字段独立存放到一个表中
3、经常一起使用的字段放到一起
水平拆分原则
1、表的水平拆分是为了解决单表数据量过大的问题
2、尽管加了完美的索引,查询效率低,写入的效率也相应的降低
3、通常对id进行hash运算,如果要拆分为5个表则使用mod ( id,5)取出O-4个值
Last updated
Was this helpful?