Mysql 36条军规

核心

不在数据库做运算

单表数据量:一年内单表纯INT不超过1000W,含CHAR不超500W。单库不超过300~400表

表字段尽量少,上限控制在20~50个

适当可以冗余(平衡范式和冗余)

拒绝大sql,大事务,大批量

字段

数值类型的字节和运用范围

如果可以,将字符串转化为数字存储。可以加快查询速度和节省空间,举例用INT代替CHAR(15)来存储IP

优先使用SET和ENUM...(可能有问题!)

避免使用NULL

少用TEXT/BLOB,如果必须使用(超过varchar最大限制64k)则必须拆分到单独的表

不在数据库存图片

索引

能不加的索引尽量不加,最好不超过字段数的20%(如:性别不加),结合核心SQL优先考虑覆盖索引(https://my.oschina.net/BearCatYN/blog/476748)

字符字段必须建前缀索引。由于字符串很长,通常可以索引开始的几个字符,而不是全部值,以节约空间并得到好的性能。(http://www.educity.cn/wenda/402373.html)

不在索引列进行数学运算和函数运算(会导致无法使用索引 => 全表扫描),如where id+1 = 100和id = 100 - 1,效率差很远

自增列或全局ID做INNODB的主键

尽量不用外键(由程序保证约束),高并发的时候容易死锁

SQL

SQL语句尽可能简单,因为一条SQL只能在一个CPU运算,在高并发的情况下,可能一条大SQL就把整个数据库堵死。而简单的SQL缓存命中率更高,减少锁表的时间(特别是MyISAM),用上多CPU

保持事务、DB连接足够短,即开即用、用完就关。与事务无关操作放到事务外面,减少锁资源的占用;在不破坏一致性前提下,使用多个短事务代替长事务(如:发帖时的图片上传等待)

尽可能少用存储过程,少用触发器,减用MySQL函数对结果进行处理(交由客户端程序负责)

尽量少用select *,只取需要数据列,为使用覆盖索引提供可能性,减少临时表生成,更安全

用in()代替or,因为or的效率是O(n),而in()的效率是O(Log n)。如:where a = 1 OR a = 100与where a IN (1, 100)

merge index往往很弱智,所以用union代替对多字段的or查询。如:select * from t where a = 1 OR b = 2与select * from t where a = 1 UNION select * from t where b = 2

尽量避免负向查找,如NOT、!=等

尽量避免%前缀模糊查询,由于使用的是B+ Tree,前缀模糊使用不了索引,导致全表扫描(后缀模糊速度相对快很多)

减少COUNT(*),使用COUNT(col),前者资源开销大,尽量少用。MyISAM不带WHERE COUNT()而INNODB带WHERE COUNT()。 计数的统计可以采用的方法:实时统计可以使用memcache,双向更新,凌晨跑基准;非实时统计尽量用单独统计表,定期重算

LIMIT高效分页:传统的方法是select * from t limit 10000, 10,推荐的方法是select * from t where id > 23423 limit 10。LIMIT的偏移量越大则越慢。还有一些高效的方法有:先取id来LIMIT偏移,减少整体的数据偏移;取到需要的id,与原表JOIN;程序取ID,然后用IN来填写。select * from t where id >= (select id from t limit 10000, 1) limit 10,select * from t INNER JOIN (select id from t limit 10000, 10) USING (id),select id from t limit 10000, 10; select * from t where id in (123, 456...)

若无需对结果进行去重,则用UNION ALL而非UNION(UNION有去重开销)

分解JOIN联接来保证高并发。高并发DB不建议进行两个表以上的JOIN

group by会默认自动升序排序,如果需要去掉排序,需要指定order by NULL

比较原则:数字对数字、字符对字符。如果数值列与字符类型作比较,同时转换成双精度;如果字符列与数值类型作比较,字符列整列转数值,且不会使用索引查询

load data导入数据比insert快约20倍(不需要刷新缓存)

尽量不使用insert...select(延迟、同步出错)

大批量更新凌晨操作,避开高峰

SQL的一些命令:explain, show profile, mysqlsla, mysqldumpslow, show slow log, show processlist, show QUERY_RESPONSE_TIME(Percona)

约定

数据库在不同时期使用不同的:实时数据用real库,模拟环境用sim库,测试用qa库,开发用dev库

禁止未经DBA确认的子查询(大部分情况优化较差,特别是WHERE中使用IN id的子查询,一般可以用JOIN改写)

不要在程序上加锁数据库,因为外部锁对数据库不可控,高并发时是灾难,并且极难调试排查(可以采用事务来解决)

统一字符集:UTF-8,校对规则:utf8_general_ci

库和表的名称统一用小写(大小写敏感、且不同操作系统都有不同的限制);字段名大小写不敏感;索引名默认为idx_字段名;库名用缩写,尽量在2~7个字母;避免用保留字命名

作者:TyrusChin

链接:http://www.jianshu.com/p/cf620ad5e8f4

來源:简书

著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 215,539评论 6 497
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 91,911评论 3 391
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 161,337评论 0 351
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 57,723评论 1 290
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 66,795评论 6 388
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,762评论 1 294
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,742评论 3 416
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,508评论 0 271
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,954评论 1 308
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,247评论 2 331
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,404评论 1 345
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,104评论 5 340
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,736评论 3 324
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,352评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,557评论 1 268
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,371评论 2 368
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,292评论 2 352

推荐阅读更多精彩内容