用尽洪荒之力整理的Mysql数据库32条军规

今天上午吐血整理了Oracle SQL性能优化的40条军规,其中很多规则也是适用于Mysql的,结果今晚发现这一篇文章——用尽洪荒之力整理的Mysql数据库32条军规,和我的竟有异曲同工之妙,当然不同的是这是由具有12年Java开发经验的老鸟写的,其见解和认识肯定比我的更加深刻,感谢前辈,现全文转载如下:

--------------------------------------------------------------split line-----------------------------------------------------

写在前面的话:

总是在灾难发生后,才想起容灾的重要性;

总是在吃过亏后,才记得曾经有人提醒过。

核心军规

1、不在数据库做运算
cpu计算务必移至业务层

2、控制单表数据量
int型不超过1000w,含char则不超过500w;
合理分表;
限制单库表数量在300以内;

3、控制列数量
字段少而精,字段数建议在20以内;

4、平衡范式与冗余
效率优先;
往往牺牲范式;

5、拒绝3B

拒绝大sql语句:big sql
拒绝大事务:big transaction
拒绝大批量:big batch

字段类军规

6、用好数值类型

tinyint(1Byte)
smallint(2Byte)
mediumint(3Byte)
int(4Byte)
bigint(8Byte)
bad case:int(1)/int(11)

7、字符转化为数字

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

8、优先使用enum或set

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

9、避免使用NULL字段

NULL字段很难查询优化;
NULL字段的索引需要额外空间;
NULL字段的复合索引无效;

  bad case:
    ‘name‘ char(32) default null
    ‘age‘ int not null
   good case:
    ‘age‘ int not null default 0

10、少用text/blob

varchar的性能会比text高很多;
实在避免不了blob,请拆表;

11、不在数据库里存图片

索引类军规

12、谨慎合理使用索引

改善查询、减慢更新;
索引一定不是越多越好(能不加就不加,要加的一定得加);
覆盖记录条数过多不适合建索引,例如“性别”;

13、字符字段必须建前缀索引

14、不在索引做列运算

bad case:
select id where age +1 = 10;

15、innodb主键推荐使用自增列;

主键建立聚簇索引;
主键不应该被修改;
字符串不应该做主键;
如果不指定主键,innodb会使用唯一且非空值索引代替;

16、不用外键

请由程序保证约束;

sql类军规

17、sql语句尽可能简单

一条sql只能在一个cpu运算;
大语句拆小语句,减少锁时间;
一条大sql可以堵死整个库;

18、简单的事务

事务时间尽可能短;

19、避免使用trig/func

触发器、函数不用;
客户端程序取而代之;

20、不用select *

消耗cpu,io,内存,带宽;
这种程序不具有扩展性;

21、OR改写为IN()

or的效率是n级别;
in的消息时log(n)级别;
in的个数建议控制在200以内;

 select id from t where phone=’159′ or phone=’136′;

 =>

 select id from t where phone in (’159′, ’136′);

22、OR改写为UNION

mysql的索引合并很弱智

 select id from t where phone = ’159′ or name = ‘john’;

 =>

 select id from t where phone=’159′

 union

 select id from t where name=’jonh’

23、避免负向%

24、慎用count(*)

25、limit高效分页

limit越大,效率越低

select id from t limit 10000, 10;

=>

select id from t where id > 10000 limit 10;

26、使用union all替代union

union有去重开销

27、少用连接join

28、少用group by

分组;
自动排序;

29、请使用同类型比较

30、使用load data导数据

load data比insert快约20倍;

31、打散批量更新

32、新能分析工具

show profile;

mysqlsla;

mysqldumpslow;

explain;

show slow log;

show processlist;

show query_response_time(percona);
时间: 2024-10-24 11:33:19

用尽洪荒之力整理的Mysql数据库32条军规的相关文章

【MySql】赶集网mysql开发36条军规

[MySql]赶集网mysql开发36条军规 2012-05-14 14:02:33 分类: Linux 写在前面的话: 总是在灾难发生后,才想起容灾的重要性: 总是在吃过亏后,才记得曾经有人提醒过. (一)核心军规 (1)不在数据库做运算 cpu计算务必移至业务层: (2)控制单表数据量 int型不超过1000w,含char则不超过500w: 合理分表: 限制单库表数量在300以内: (3)控制列数量 字段少而精,字段数建议在20以内: (4)平衡范式与冗余 效率优先: 往往牺牲范式: (5)

检查所有PostgreSQL服务器所有数据库schema下所有表大小并统一整理到MySQL数据库中

目前开发环境共有40台左右PostgreSQL数据库服务器,现在将这些数据库服务器所有数据库的所有schema由脚本统一收集并写入MySQL数据库中,可以做个定时任务,每隔一段时间运行一次,实时收集数据 在MySQL数据库中创建元数据表 mysql> desc t_postgres_instance; +-------------------+--------------------------------------+------+-----+-------------------+-----

用尽洪荒之力解决Apple Store ipv6审核通关---linux服务器支持ipv6

强势的库克时代到来,苹果开启了强制IPV6审核,大家也知道中国现在的情况,除了教育网实验性的支持IPV6,ISP运营商还不支持,想必大家都陆陆续续的遭受到了苹果无情的拒绝,以前开个加急,审核时间也就一天,快的话2小时就可以过,而现在一次又一次的拒绝,让国内开发者苦不堪言.不过聪明的中国人,不会被这样的问题打倒的,中国有句古话叫道高一尺,魔高一丈.公司的两个APP在经过两轮苹果残忍拒绝后,在7月底还是审核通过了.在此跟大家分享一下审核通关的经验.最近看大家都在聊ipv6审核,有的运气好,没做任何改

看江湖老炮用尽洪荒之力解读网络协议(下)

作者言:老炮总结的有些协议比喻也不是很恰当,毕竟网络协议是一门科学,而江湖规矩是口口相传的道义:如果把此文当成一份凉菜,"老炮如是说"的话语只能做为一点调味,具体调的好不好,老炮也恍惚,老炮只是用心在调,咸了淡了您多包涵,欢迎品尝.上篇叙述了网络协议的上三路,本篇介绍网络协议的下四路.下面看一位老炮如何解读这些网络协议(下)传输层传输层是整个协议层次结构的核心,是惟一负责总体数据传输和控制的一层.它属于OSI模型7层的中间层,网络层只是根据网络地址将源结点发出的数据包传送到目的结点,而

MySQL数据库25条规范解读(转)

一.基础规范 (1)必须使用UTF8字符集 解读:万国码,无需转码,无乱码风险,节省空间(由于移动设备原因最好使用utf8mb4) (2)禁止使用存储过程.视图.触发器.Event 解读:高并发大数据的互联网业务,架构设计思路是"解放数据库CPU,将计算转移到服务层",并发量大的情况下,这些功能很可能将数据库拖死,业务逻辑放到服务层具备更好的扩展性,能够轻易实现"增机器就加性能".数据库擅长存储与索引,CPU计算还是上移吧 (3)禁止存储大文件或者大照片 解读:为何

赶集网mysql开发36条军规

写在前面的话: 总是在灾难发生后,才想起容灾的重要性: 总是在吃过亏后,才记得曾经有人提醒过. (一)核心军规 (1)不在数据库做运算 cpu计算务必移至业务层: (2)控制单表数据量 int型不超过1000w,含char则不超过500w: 合理分表: 限制单库表数量在300以内: (3)控制列数量 字段少而精,字段数建议在20以内: (4)平衡范式与冗余 效率优先: 往往牺牲范式: (5)拒绝3B 拒绝大sql语句:big sql 拒绝大事物:big transaction 拒绝大批量:big

MySQL开发36条军规

转载地址:http://blog.itpub.net/22664653/viewspace-723506/ 写在前面的话: 总是在灾难发生后,才想起容灾的重要性: 总是在吃过亏后,才记得曾经有人提醒过. (一)核心军规 (1)不在数据库做运算 cpu计算务必移至业务层: (2)控制单表数据量 int型不超过1000w,含char则不超过500w: 合理分表: 限制单库表数量在300以内: (3)控制列数量 字段少而精,字段数建议在20以内: (4)平衡范式与冗余 效率优先: 往往牺牲范式: (5

58到家数据库30条军规解读

此篇文章来源于微信公众号[架构师之路],为了帮助记忆,现在抄写与此,如有侵权,告知立刻删除,谢谢! 军规使用场景:并发量大.数据量大的互联网业务 基础规范 必须使用 InnoDB 存储引擎:支持事务.行级锁.并发性能更好.CPU及内存缓存页优化使得资源利用率更高 必须使用 UTF8 字符集:万国码.无需转码.五乱码风险,节省空间 数据表.数据字段必须加入 中文注释 :好记忆不如烂笔头 禁止 使用存储过程.视图.触发器.Event:高并发大数据的互联网业务,架构设计思路是"解放数据库CPU,将计算

58到家数据库30条军规

军规适用场景:并发量大.数据量大的互联网业务 军规:介绍内容 解读:讲解原因,解读比军规更重要 一.基础规范 (1)必须使用InnoDB存储引擎 解读:支持事务.行级锁.并发性能更好.CPU及内存缓存页优化使得资源利用率更高 (2)必须使用UTF8字符集 解读:万国码,无需转码,无乱码风险,节省空间 和DBA负责人确认后,纠正为"新库默认使用utf8mb4字符集". 这点感谢网友的提醒,utf8mb4是utf8的超集,emoji表情以及部分不常见汉字在utf8下会表现为乱码,故需要升级