mysql优化军规

一,核心军规

不在数据库做计算,cpu计算务必移至业务层

控制单表数据量,单表记录控制在千万级

控制列数量,字段数控制在20以内

平衡范式与冗余,为提高效率可以牺牲范式设计,冗余数据

拒绝3B(big),大sql,大事务,大批量

二,字段类军规

用好数值类型

tinyint(1Byte)

smallint(2Byte)

mediumint(3Byte)

int(4Byte)

bigint(8Byte)

bad case:int(1)/int(11)

有些字符转化为数字

用int而不是char(15)存储ip

优先使用enum或set

例如:`sex` enum (‘F’, ‘M’)

避免使用NULL字段

NULL字段很难查询优化

NULL字段的索引需要额外空间

NULL字段的复合索引无效

bad case:

`name` char(32) default null

`age` int not null

good case:

`age` int not null default 0

不在数据库里存图片

三,索引类军规

谨慎合理使用索引

改善查询、减慢更新

索引一定不是越多越好(能不加就不加,要加的一定得加)

覆盖记录条数过多不适合建索引,例如“性别”

字符字段必须建前缀索引

不在索引做列运算

bad case:

select id where age +1 = 10;

innodb主键合理使用自增列

主键建立聚簇索引

主键不应该被修改

字符串不应该做主键

如果不指定主键,innodb会使用唯一且非空值索引代替

不用外键,请由程序保证约束

四,sql类军规

sql语句尽可能简单

一条sql只能在一个cpu运算

大语句拆小语句,减少锁时间

一条大sql可以堵死整个库

简单的事务

事务时间尽可能短

bad case:

上传图片事务

避免使用触发器,用户自定义函数,请由程序取而代之

不用select *

消耗cpu,io,内存,带宽

这种程序不具有扩展性

OR改写为IN()

OR改写为UNION

画外音:最新的mysql内核已经进行了相关优化

limit高效分页

limit越大,效率越低

select id from t limit 10000, 10;

应该改为 =>

select id from t where id > 10000 limit 10;

使用union all替代union,union有去重开销

尽量不用连接join

务必请使用“同类型”进行比较,否则可能全表扫面

打散批量更新

使用新能分析工具

show profile;

mysqlsla;

mysqldumpslow;

explain;

show slow log;

show processlist;

show query_response_time(percona)

©著作权归作者所有,转载或内容合作请联系作者
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。

推荐阅读更多精彩内容

  • 数据库军规的背景是“并发量大、数据量大的互联网业务”,这类业务架构设计的重点往往是吞吐量,性能优先(和钱相关的少部...
    伟宝宝_7288阅读 559评论 0 0
  • 转 # https://www.cnblogs.com/easypass/archive/2010/12/ 08/...
    吕品㗊阅读 9,848评论 0 44
  • 1. Java基础部分 基础部分的顺序:基本语法,类相关的语法,内部类的语法,继承相关的语法,异常的语法,线程的语...
    子非鱼_t_阅读 31,805评论 18 399
  • 有一项统计,朋友圈点赞最高的晒图前三名分别是:自拍、自黑、美食。 食物照可谓是朋友圈“消毒大赛”,除了把食物拍出美...
    马xiao若阅读 14,325评论 24 210
  • 昨天在朋友圈看到一段文字。 “我就希望我喜欢的人每天缠着我,缠着我聊天,每天问我‘都去哪里了呀?都干嘛了呀?吃的什...
    薛瑾年阅读 891评论 25 30