mysql的21个好习惯
每一个好习惯都是一个财富,本文基于mysql,分享sql的21个好习惯。
写完SQL先explain,查看执行计划(SQL性能优化)
- 日常开发写SQL的时候,尽量养成这个好习惯:写完SQL后,用explain分析一下,尤其注意走不走索引
1 | EXPLAIN SELECT * FROM `user` WHERE userid = 10086 and age = 18; |
- 操作delete或update语句,夹limit(SQL后悔药)
在执行删除或者更新操作时,尽量加上limit,以下面这条SQL为例:
1 | delete from euser where age > 30 limit 200; |
使用limit的好处:
- **[降低写错SQL的代价],你在执行这个SQL的时候,如果不加limit,执行的时候一个[不小心手抖],就会可能导致数据全部删除,如果[删除]**错了呢?但是加上了limit200的话,就不一样了,如果删除错了,也仅仅丢失了200条数据,而不是整个数据库,可以通过binlog日志快速恢复
- **[SQL的执行效率可能更高]**,在SQL行中,加了limit1,如果第一条就命中目标就return,没有limit的话,还会继续执行
- **[避免了长事务]**,delete执行时,如果age加了索引。mysql会将所有相关的行加写锁和间隙锁,所有执行相关行都会被锁住,如果删除数量大,会直接影响相关业务无法进行
- **[数据量大的话,容易把CPU打满]**,如果你删除数据量很大时,不加limit限制一下条数的话,很容易把cpu打满,导致越删越慢
- 设计表的时候,所有的表和字段都添加相应的注释(SQL规范优雅)
这个好习惯一定要养成,设计数据表的时候,所有表和字段都应该添加响应的注释,后面更容易维护
正例:
1 | CREATE TABLE `account` ( |
反例:
1 | CREATE TABLE `account` ( |
- SQL书写格式,关键字大小保持一致,使用缩进(SQL规范优雅)
正例:
1 | SELECT stu.name, sum(stu.score) |
反例:
1 | SELECT stu.name, sum(stu.score) from Student stu WHERE stu.classNo = '1班' group by stu.name; |
显然,统一关键字大小写一致,使用缩进对其,会使你的SQL看起来更优雅。
- INSERT语句表明对应的字段名称(SQL规范优化)
正例:
1 | insert into Student values ('666','捡田螺的小男孩','100'); |
反例:
1 | insert into Student(student_id,name,score) values ('666','捡田螺的小男孩','100'); |
变更SQL操作先在测试环境执行,写明详细步骤及回滚方案,并在上生产环境前review(SQL后悔药)
- 变更SQL操作先在测试环境测试,避免有语法错误就直接放到了生产环境上
- 变更SQL操作要写明操作步骤,尤其有依赖关系的时候,比如先修改表结构在补充对应的数据
- 变更sql操作应该有回滚方案,并在上生产之前,review对应变更的SQL
设计数据库表的时候,加上三个字段,主键,create_time,update_time(SQL规范优雅)
反例:
1 | CREATE TABLE `account` ( |
正例:
1 | CREATE TABLE `account` ( |
理由:
- 主键一定要加上,没有主键的表示没有灵魂的
- 创建时间和更新时间的表,还是建议加上,详细审计,跟踪记录,都是有用的
阿里开发手册也是有这个的,如图:
- 写完SQL,检查where,order by, group by后面的列,多表关联的列是否已加索引,优先考虑组合索引(SQL性能优化)
正例:
1 | -- 添加索引 |
反例:
1 | select * from user where address ='深圳' order by age ; |
- 修改或删除重要数据之前,要先备份(SQL后悔药)
如果要修改或者删除数据,在执行SQL前一定要先备份要修改的数据,万一误操作,还能回滚
- where后面的字段,留意其数据类型的隐式转换(SQL性能优化)
反例:
1 | -- userid 是varchar字符串类型 |
正例:
1 | select * from user where userid ='123'; |
理由:因为不加单引号的时候,是字符串和数字比较,他们类型不匹配,mysql会做隐式的类型转换,把他们转换为浮点数在做比较,会导致索引丢失
- 尽量把所有的列都定义为NOT NULL(SQL规范优雅)
- **[NOT NULL列更节省空间]**,NULL列需要一个额外的字节判断是否为NULL的标志位
- **[NULL列需要注意空指针问题]**,在计算和比较的时候,需要注意空指针问题
- 修改或者删除的时候,先where查一下,确认后在补充delete或者update(SQL后悔药)
尤其在生产环境的时候,遇到修改或者删除的sql,先加where查询一下,确认之后,再执行update或delete操作
- 减少不必要的字段返回,使用select <具体字段> 替代select * (SQL性能优化)
反例:
1 | select * from employee; |
正例:
1 | select id,name from employee; |
理由:
- 节省资源,减少网络开销
- 可能用到覆盖索引,减少回表,提高查询效率
- 所有表必须是INNODB存储引擎(SQL规范优雅)
Innodb**[支持事务,支持行锁,更好的恢复性]**,高并发下性能更好,没有特殊要求,所有表必须使用INNODB存储引擎
- 数据库和表的字符集统一使用UTF8(SQL规范优雅)
统一使用UTF8编码:
- 可以避免乱码问题
- 可以避免不同字符集比较转换,从而导致索引失效
- 尽量使用varchar代替char(SQL性能优化)
反例:
1 | `deptName` char(100) DEFAULT NULL COMMENT '部门名称' |
正例:
1 | `deptName` varchar(100) DEFAULT NULL COMMENT '部门名称' |
理由:
- 变长字段存储空间小,可以节省存储空间
- 对于查询来说,在一个相对较小的字段内进行搜索,效率更高
- 如果修改字段含义或者对字符表示的状态进行追加时,需要及时更新字段注释(SQL规范优雅)
这个点,在阿里开发手册中,mysql的规约,你的字段,尤其是枚举字段,如果含义被修改了,或者追加状态的时候,为了后面更好的维护,需要及时更新字段的注释
- SQl修改数据,要养成begin+commit事务的习惯(SQL后悔药)
正例:
1 | begin; |
反例:
1 | update account set balance =1000000 |
- 索引命名要规范,主键索引名为pk_字段名:唯一索引命名为uk_字段名,普通索引为idx_字段名(SQL规范优雅)
说明:pk_ 即primary_key ,uk_ 即unique_key , idx_ 即为index
- where从句中不对列进行函数转换和表达式计算
假如loginTime加了索引
反例:
1 | select userId,loginTime from loginuser where Date_ADD(loginTime,Interval 7 DAY) >=now(); |
正例:
1 | explain select userId,loginTime from loginuser where loginTime >= Date_ADD(NOW(),INTERVAL - 7 DAY); |
理由:
索引上使用了mysql内置函数,索引失效
- 如果修改,更新数据过多,考虑使用批量
反例:
1 | delete from account limit 100000; |
正例:
1 | for each(200次) |
理由:
- 大批量操作会造成主从延迟
- 大批量操作会产生大事务,阻塞
- 大批量操作,数据量过大,会把cpu打满
若你觉得我的文章对你有帮助,欢迎点击上方按钮对我打赏
扫描二维码,分享此文章