mysql 避坑宝典(转)

原文：https://learnku.com/articles/25270

一、前言

最近偶然翻翻一些博客，发现依然有一些介绍 mysql 常见优化场景的东西，甚是有趣。想起了以前在公司作的 SQL 规范相关工做。独乐了不如众乐乐，独学习不如众分享，跟你们分享下本身在这个环节的一些心得。

以前无非是根据一些经验和书籍，列出常见的场景。直到有一次看到了小米的开源工具，SOAR，简直是被震惊的感受。这个工具经过是 SQL 语法树的分析，结合小米 DBA 多年经验的总结，进行了一系列启发规则的校验。最后给出 SQL 的优化建议，甚是好用。

固然，本篇文章不会介绍 SOAR 的具体使用，咱们来聊聊那些 DBA 总结出来的启发规则。根据启发规则，你们也能解决平时遇到的相关 SQL 问题。

启发式规则建议

二、建议使用 AS 关键字显示声明一个别名

• Item: ALI.001
• Severity: L0
• Content: 在列或表别名 (如 "tbl AS alias") 中，明确使用 AS 关键字比隐含别名 (如 "tbl alias") 更易懂。
• Case:

select name from tbl t1 where id < 1000

三、不建议给列通配符 '*' 设置别名

• Item: ALI.002
• Severity: L8
• Content: 例: "SELECT tbl.* col1, col2" 上面这条 SQL 给列通配符设置了别名，这样的 SQL 可能存在逻辑错误。您可能意在查询 col1, 可是代替它的是重命名的是 tbl 的最后一列。
• Case:

select tbl.* as c1,c2,c3 from tbl where id < 1000

四、别名不要与表或列的名字相同

• Item: ALI.003
• Severity: L1
• Content: 表或列的别名与其真实名称相同，这样的别名会使得查询更难去分辨。
• Case:

select name from tbl as tbl where id < 1000

五、修改表的默认字符集不会改表各个字段的字符集

• Item: ALT.001
• Severity: L4
• Content: 不少初学者会将 ALTER TABLE tbl_name [DEFAULT] CHARACTER SET 'UTF8' 误认为会修改全部字段的字符集，但实际上它只会影响后续新增的字段不会改表已有字段的字符集。若是想修改整张表全部字段的字符集建议使用 ALTER TABLE tbl_name CONVERT TO CHARACTER SET charset_name;
• Case:

ALTER TABLE tbl_name CONVERT TO CHARACTER SET charset_name;

六、同一张表的多条 ALTER 请求建议合为一条

• Item: ALT.002
• Severity: L2
• Content: 每次表结构变动对线上服务都会产生影响，即便是可以经过在线工具进行调整也请尽可能经过合并 ALTER 请求的试减小操做次数。
• Case:

ALTER TABLE tbl ADD COLUMN col int, ADD INDEX idx_col (col);

七、删除列为高危操做，操做前请注意检查业务逻辑是否还有依赖

• Item: ALT.003
• Severity: L0
• Content: 如业务逻辑依赖未彻底消除，列被删除后可能致使数据没法写入或没法查询到已删除列数据致使程序异常的状况。这种状况下即便经过备份数据回滚也会丢失用户请求写入的数据。
• Case:

ALTER TABLE tbl DROP COLUMN col;

八、删除主键和外键为高危操做，操做前请与 DBA 确认影响

• Item: ALT.004
• Severity: L0
• Content: 主键和外键为关系型数据库中两种重要约束，删除已有约束会打破已有业务逻辑，操做前请业务开发与 DBA 确认影响，三思而行。
• Case:

ALTER TABLE tbl DROP PRIMARY KEY;

九、不建议使用前项通配符查找

• Item: ARG.001
• Severity: L4
• Content: 例如 "％foo"，查询参数有一个前项通配符的状况没法使用已有索引。
• Case:

select c1,c2,c3 from tbl where name like '%foo'

十、没有通配符的 LIKE 查询

• Item: ARG.002
• Severity: L1
• Content: 不包含通配符的 LIKE 查询可能存在逻辑错误，由于逻辑上它与等值查询相同。
• Case:

select c1,c2,c3 from tbl where name like 'foo'

十一、参数比较包含隐式转换，没法使用索引

• Item: ARG.003
• Severity: L4
• Content: 隐式类型转换有没法命中索引的风险，在高并发、大数据量的状况下，命不中索引带来的后果很是严重。
• Case:

SELECT * FROM sakila.film WHERE length >= '60';

十二、IN (NULL)/NOT IN (NULL) 永远非真

• Item: ARG.004
• Severity: L4
• Content: 正确的做法是 col IN ('val1', 'val2', 'val3') OR col IS NULL
• Case:

SELECT * FROM tb WHERE col IN (NULL);

1三、IN 要慎用，元素过多会致使全表扫描

• Item: ARG.005
• Severity: L1
• Content: 如：select id from t where num in (1,2,3) 对于连续的数值，能用 BETWEEN 就不要用 IN 了：select id from t where num between 1 and 3。而当 IN 值过多时 MySQL 也可能会进入全表扫描致使性能急剧降低。
• Case:

select id from t where num in(1,2,3)

1四、应尽可能避免在 WHERE 子句中对字段进行 NULL 值判断

• Item: ARG.006
• Severity: L1
• Content: 使用 IS NULL 或 IS NOT NULL 将可能致使引擎放弃使用索引而进行全表扫描，如：select id from t where num is null; 能够在 num 上设置默认值 0，确保表中 num 列没有 NULL 值，而后这样查询： select id from t where num=0;
• Case:

select id from t where num is null

1五、避免使用模式匹配

• Item: ARG.007
• Severity: L3
• Content: 性能问题是使用模式匹配操做符的最大缺点。使用 LIKE 或正则表达式进行模式匹配进行查询的另外一个问题，是可能会返回意料以外的结果。最好的方案就是使用特殊的搜索引擎技术来替代 SQL，好比 Apache Lucene。另外一个可选方案是将结果保存起来从而减小重复的搜索开销。若是必定要使用 SQL，请考虑在 MySQL 中使用像 FULLTEXT 索引这样的第三方扩展。但更普遍地说，您不必定要使用 SQL 来解决全部问题。
• Case:

select c_id,c2,c3 from tbl where c2 like 'test%'

1六、OR 查询索引列时请尽可能使用 IN 谓词

• Item: ARG.008
• Severity: L1
• Content: IN-list 谓词能够用于索引检索，而且优化器能够对 IN-list 进行排序，以匹配索引的排序序列，从而得到更有效的检索。请注意，IN-list 必须只包含常量，或在查询块执行期间保持常量的值，例如外引用。
• Case:

SELECT c1,c2,c3 FROM tbl WHERE c1 = 14 OR c1 = 17

1七、引号中的字符串开头或结尾包含空格

• Item: ARG.009
• Severity: L1
• Content: 若是 VARCHAR 列的先后存在空格将可能引发逻辑问题，如在 MySQL 5.5 中 'a' 和 'a ' 可能会在查询中被认为是相同的值。
• Case:

SELECT 'abc '

1八、不要使用 hint，如：sql_no_cache, force index, ignore key, straight join 等

• Item: ARG.010
• Severity: L1
• Content: hint 是用来强制 SQL 按照某个执行计划来执行，但随着数据量变化咱们没法保证本身当初的预判是正确的。
• Case:

SELECT * FROM t1 USE INDEX (i1) ORDER BY a;

1九、不要使用负向查询，如：NOT IN/NOT LIKE

• Item: ARG.011
• Severity: L3
• Content: 请尽可能不要使用负向查询，这将致使全表扫描，对查询性能影响较大。
• Case:

select id from t where num not in(1,2,3);

20、一次性 INSERT/REPLACE 的数据过多

• Item: ARG.012
• Severity: L2
• Content: 单条 INSERT/REPLACE 语句批量插入大量数据性能较差，甚至可能致使从库同步延迟。为了提高性能，减小批量写入数据对从库同步延时的影响，建议采用分批次插入的方法。
• Case:

INSERT INTO tb (a) VALUES (1), (2)

2一、最外层 SELECT 未指定 WHERE 条件

• Item: CLA.001
• Severity: L4
• Content: SELECT 语句没有 WHERE 子句，可能检查比预期更多的行 (全表扫描)。对于 SELECT COUNT (*) 类型的请求若是不要求精度，建议使用 SHOW TABLE STATUS 或 EXPLAIN 替代。
• Case:

select id from tbl

2二、不建议使用 ORDER BY RAND ()

• Item: CLA.002
• Severity: L3
• Content: ORDER BY RAND () 是从结果集中检索随机行的一种很是低效的方法，由于它会对整个结果进行排序并丢弃其大部分数据。
• Case:

select name from tbl where id < 1000 order by rand(number)

2三、不建议使用带 OFFSET 的 LIMIT 查询

• Item: CLA.003
• Severity: L2
• Content: 使用 LIMIT 和 OFFSET 对结果集分页的复杂度是 O (n^2)，而且会随着数据增大而致使性能问题。采用 “书签” 扫描的方法实现分页效率更高。
• Case:

select c1,c2 from tbl where name=xx order by number limit 1 offset 20

2四、不建议对常量进行 GROUP BY

• Item: CLA.004
• Severity: L2
• Content: GROUP BY 1 表示按第一列进行 GROUP BY。若是在 GROUP BY 子句中使用数字，而不是表达式或列名称，当查询列顺序改变时，可能会致使问题。
• Case:

select col1,col2 from tbl group by 1

2五、ORDER BY 常数列没有任何意义

• Item: CLA.005
• Severity: L2
• Content: SQL 逻辑上可能存在错误；最多只是一个无用的操做，不会更改查询结果。
• Case:

select id from test where id=1 order by id

2六、在不一样的表中 GROUP BY 或 ORDER BY

• Item: CLA.006
• Severity: L4
• Content: 这将强制使用临时表和 filesort，可能产生巨大性能隐患，而且可能消耗大量内存和磁盘上的临时空间。
• Case:

select tb1.col, tb2.col from tb1, tb2 where id=1 group by tb1.col, tb2.col

2七、ORDER BY 语句对多个不一样条件使用不一样方向的排序没法使用索引

• Item: CLA.007
• Severity: L2
• Content: ORDER BY 子句中的全部表达式必须按统一的 ASC 或 DESC 方向排序，以便利用索引。
• Case:

select c1,c2,c3 from t1 where c1='foo' order by c2 desc, c3 asc

2八、请为 GROUP BY 显示添加 ORDER BY 条件

• Item: CLA.008
• Severity: L2
• Content: 默认 MySQL 会对 'GROUP BY col1, col2, ...' 请求按以下顺序排序 'ORDER BY col1, col2, ...'。若是 GROUP BY 语句不指定 ORDER BY 条件会致使无谓的排序产生，若是不须要排序建议添加 'ORDER BY NULL'。
• Case:

select c1,c2,c3 from t1 where c1='foo' group by c2

2九、ORDER BY 的条件为表达式

• Item: CLA.009
• Severity: L2
• Content: 当 ORDER BY 条件为表达式或函数时会使用到临时表，若是在未指定 WHERE 或 WHERE 条件返回的结果集较大时性能会不好。
• Case:

select description from film where title ='ACADEMY DINOSAUR' order by length-language_id;

30、GROUP BY 的条件为表达式

• Item: CLA.010
• Severity: L2
• Content: 当 GROUP BY 条件为表达式或函数时会使用到临时表，若是在未指定 WHERE 或 WHERE 条件返回的结果集较大时性能会不好。
• Case:

select description from film where title ='ACADEMY DINOSAUR' GROUP BY length-language_id;

3一、建议为表添加注释

• Item: CLA.011
• Severity: L1
• Content: 为表添加注释可以使得表的意义更明确，从而为往后的维护带来极大的便利。
• Case:

CREATE TABLE test1 (ID bigint(20) NOT NULL AUTO_INCREMENT,c1 varchar(128) DEFAULT NULL,PRIMARY KEY (ID)) ENGINE=InnoDB DEFAULT CHARSET=utf8

3二、将复杂的裹脚布式查询分解成几个简单的查询

• Item: CLA.012
• Severity: L2
• Content: SQL 是一门极具表现力的语言，您能够在单个 SQL 查询或者单条语句中完成不少事情。但这并不意味着必须强制只使用一行代码，或者认为使用一行代码就搞定每一个任务是个好主意。经过一个查询来得到全部结果的常见后果是获得了一个笛卡儿积。当查询中的两张表之间没有条件限制它们的关系时，就会发生这种状况。没有对应的限制而直接使用两张表进行联结查询，就会获得第一张表中的每一行和第二张表中的每一行的一个组合。每个这样的组合就会成为结果集中的一行，最终您就会获得一个行数不少的结果集。重要的是要考虑这些查询很难编写、难以修改和难以调试。数据库查询请求的日益增长应该是预料之中的事。经理们想要更复杂的报告以及在用户界面上添加更多的字段。若是您的设计很复杂，而且是一个单一查询，要扩展它们就会很费时费力。不论对您仍是项目来讲，时间花在这些事情上面不值得。将复杂的意大利面条式查询分解成几个简单的查询。当您拆分一个复杂的 SQL 查询时，获得的结果多是不少相似的查询，可能仅仅在数据类型上有所不一样。编写全部的这些查询是很乏味的，所以，最好可以有个程序自动生成这些代码。SQL 代码生成是一个很好的应用。尽管 SQL 支持用一行代码解决复杂的问题，但也别作不切实际的事情。
• Case: 这是一条很长很长的 SQL，案例略。

3三、不建议使用 HAVING 子句

• Item: CLA.013
• Severity: L3
• Content: 将查询的 HAVING 子句改写为 WHERE 中的查询条件，能够在查询处理期间使用索引。
• Case:

SELECT s.c_id,count(s.c_id) FROM s where c = test GROUP BY s.c_id HAVING s.c_id <> '1660' AND s.c_id <> '2' order by s.c_id

3四、删除全表时建议使用 TRUNCATE 替代 DELETE

• Item: CLA.014
• Severity: L2
• Content: 删除全表时建议使用 TRUNCATE 替代 DELETE
• Case:

delete from tbl

3五、UPDATE 未指定 WHERE 条件

• Item: CLA.015
• Severity: L4
• Content: UPDATE 不指定 WHERE 条件通常是致命的，请您三思后行
• Case:

update tbl set col=1

3六、不要 UPDATE 主键

• Item: CLA.016
• Severity: L2
• Content: 主键是数据表中记录的惟一标识符，不建议频繁更新主键列，这将影响元数据统计信息进而影响正常的查询。
• Case:

update tbl set col=1

3七、不建议使用 SELECT * 类型查询

• Item: COL.001
• Severity: L1
• Content: 当表结构变动时，使用 * 通配符选择全部列将致使查询的含义和行为会发生更改，可能致使查询返回更多的数据。
• Case:

select * from tbl where id=1

3八、INSERT/REPLACE 未指定列名

• Item: COL.002
• Severity: L2
• Content: 当表结构发生变动，若是 INSERT 或 REPLACE 请求不明确指定列名，请求的结果将会与预想的不一样；建议使用 “INSERT INTO tbl (col1，col2) VALUES ...” 代替。
• Case:

insert into tbl values(1,'name')

3九、建议修改自增 ID 为无符号类型

• Item: COL.003
• Severity: L2
• Content: 建议修改自增 ID 为无符号类型
• Case:

create table test(id int(11) NOT NULL AUTO_INCREMENT)

40、请为列添加默认值

• Item: COL.004
• Severity: L1
• Content: 请为列添加默认值，若是是 ALTER 操做，请不要忘记将原字段的默认值写上。字段无默认值，当表较大时没法在线变动表结构。
• Case:

CREATE TABLE tbl (col int) ENGINE=InnoDB;

4一、列未添加注释

• Item: COL.005
• Severity: L1
• Content: 建议对表中每一个列添加注释，来明确每一个列在表中的含义及做用。
• Case:

CREATE TABLE tbl (col int) ENGINE=InnoDB;

4二、表中包含有太多的列

• Item: COL.006
• Severity: L3
• Content: 表中包含有太多的列
• Case:

CREATE TABLE tbl ( cols ....);

4三、可以使用 VARCHAR 代替 CHAR， VARBINARY 代替 BINARY

• Item: COL.008
• Severity: L1
• Content: 为首先变长字段存储空间小，能够节省存储空间。其次对于查询来讲，在一个相对较小的字段内搜索效率显然要高些。
• Case:

create table t1(id int,name char(20),last_time date)

4四、建议使用精确的数据类型

• Item: COL.009
• Severity: L2
• Content: 实际上，任何使用 FLOAT, REAL 或 DOUBLE PRECISION 数据类型的设计都有多是反模式。大多数应用程序使用的浮点数的取值范围并不须要达到 IEEE 754 标准所定义的最大 / 最小区间。在计算总量时，非精确浮点数所积累的影响是严重的。使用 SQL 中的 NUMERIC 或 DECIMAL 类型来代替 FLOAT 及其相似的数据类型进行固定精度的小数存储。这些数据类型精确地根据您定义这一列时指定的精度来存储数据。尽量不要使用浮点数。
• Case:

CREATE TABLE tab2 (p_id  BIGINT UNSIGNED NOT NULL,a_id  BIGINT UNSIGNED NOT NULL,hours float not null,PRIMARY KEY (p_id, a_id))

4五、不建议使用 ENUM 数据类型

• Item: COL.010
• Severity: L2
• Content: ENUM 定义了列中值的类型，使用字符串表示 ENUM 里的值时，实际存储在列中的数据是这些值在定义时的序数。所以，这列的数据是字节对齐的，当您进行一次排序查询时，结果是按照实际存储的序数值排序的，而不是按字符串值的字母顺序排序的。这可能不是您所但愿的。没有什么语法支持从 ENUM 或者 check 约束中添加或删除一个值；您只能使用一个新的集合从新定义这一列。若是您打算废弃一个选项，您可能会为历史数据而烦恼。做为一种策略，改变元数据 —— 也就是说，改变表和列的定义 —— 应该是不常见的，而且要注意测试和质量保证。有一个更好的解决方案来约束一列中的可选值：建立一张检查表，每一行包含一个容许在列中出现的候选值；而后在引用新表的旧表上声明一个外键约束。
• Case:

create table tab1(status ENUM('new','in progress','fixed'))

4六、当须要惟一约束时才使用 NULL，仅当列不能有缺失值时才使用 NOT NULL

• Item: COL.011
• Severity: L0
• Content: NULL 和 0 是不一样的，10 乘以 NULL 仍是 NULL。NULL 和空字符串是不同的。将一个字符串和标准 SQL 中的 NULL 联合起来的结果仍是 NULL。NULL 和 FALSE 也是不一样的。AND、OR 和 NOT 这三个布尔操做若是涉及 NULL，其结果也让不少人感到困惑。当您将一列声明为 NOT NULL 时，也就是说这列中的每个值都必须存在且是有意义的。使用 NULL 来表示任意类型不存在的空值。 当您将一列声明为 NOT NULL 时，也就是说这列中的每个值都必须存在且是有意义的。
• Case:

select c1,c2,c3 from tbl where c4 is null or c4 <> 1

4七、BLOB 和 TEXT 类型的字段不可设置为 NULL

• Item: COL.012
• Severity: L5
• Content: BLOB 和 TEXT 类型的字段不可设置为 NULL
• Case:

CREATE TABLE tbl ( id int(10) unsigned NOT NULL AUTO_INCREMENT, c longblob, PRIMARY KEY (id));

4八、TIMESTAMP 类型未设置默认值

• Item: COL.013
• Severity: L4
• Content: TIMESTAMP 类型未设置默认值
• Case:

CREATE TABLE tbl( id bigint not null, create_time timestamp);

4九、为列指定了字符集

• Item: COL.014
• Severity: L5
• Content: 建议列与表使用同一个字符集，不要单独指定列的字符集。
• Case:

CREATE TABLE tb2 ( id int(11) DEFAULT NULL, col char(10) CHARACTER SET utf8 DEFAULT NULL)

50、BLOB 类型的字段不可指定默认值

• Item: COL.015
• Severity: L4
• Content: BLOB 类型的字段不可指定默认值
• Case:

CREATE TABLE tbl ( id int(10) unsigned NOT NULL AUTO_INCREMENT, c blob NOT NULL DEFAULT '', PRIMARY KEY (id));

5一、整型定义建议采用 INT (10) 或 BIGINT (20)

• Item: COL.016
• Severity: L1
• Content: INT (M) 在 integer 数据类型中，M 表示最大显示宽度。 在 INT (M) 中，M 的值跟 INT (M) 所占多少存储空间并没有任何关系。 INT (3)、INT (4)、INT (8) 在磁盘上都是占用 4 bytes 的存储空间。
• Case:

CREATE TABLE tab (a INT(1));

5二、VARCHAR 定义长度过长

• Item: COL.017
• Severity: L2
• Content: varchar 是可变长字符串，不预先分配存储空间，长度不要超过 255，若是存储长度过长 MySQL 将定义字段类型为 text，独立出来一张表，用主键来对应，避免影响其它字段索引效率。
• Case:

CREATE TABLE tab (a varchar(3500));

5三、消除没必要要的 DISTINCT 条件

• Item: DIS.001
• Severity: L1
• Content: 太多 DISTINCT 条件是复杂的裹脚布式查询的症状。考虑将复杂查询分解成许多简单的查询，并减小 DISTINCT 条件的数量。若是主键列是列的结果集的一部分，则 DISTINCT 条件可能没有影响。
• Case:

SELECT DISTINCT c.c_id,count(DISTINCT c.c_name),count(DISTINCT c.c_e),count(DISTINCT c.c_n),count(DISTINCT c.c_me),c.c_d FROM (select distinct id, name from B) as e WHERE e.country_id = c.country_id

5四、COUNT (DISTINCT) 多列时结果可能和你预想的不一样

• Item: DIS.002
• Severity: L3
• Content: COUNT (DISTINCT col) 计算该列除 NULL 以外的不重复行数，注意 COUNT (DISTINCT col, col2) 若是其中一列全为 NULL 那么即便另外一列有不一样的值，也返回 0。
• Case:

SELECT COUNT(DISTINCT col, col2) FROM tbl;

5五、DISTINCT * 对有主键的表没有意义

• Item: DIS.003
• Severity: L3
• Content: 当表已经有主键时，对全部列进行 DISTINCT 的输出结果与不进行 DISTINCT 操做的结果相同，请不要多此一举。
• Case:

SELECT DISTINCT * FROM film;

5六、避免在 WHERE 条件中使用函数或其余运算符

• Item: FUN.001
• Severity: L2
• Content: 虽然在 SQL 中使用函数能够简化不少复杂的查询，但使用了函数的查询没法利用表中已经创建的索引，该查询将会是全表扫描，性能较差。一般建议将列名写在比较运算符左侧，将查询过滤条件放在比较运算符右侧。也不建议在查询比较条件两侧书写多余的括号，这会对阅读产生比较大的困扰。
• Case:

select id from t where substring(name,1,3)='abc'

5七、指定了 WHERE 条件或非 MyISAM 引擎时使用 COUNT (*) 操做性能不佳

• Item: FUN.002
• Severity: L1
• Content: COUNT () 的做用是统计表行数，COUNT (COL) 的做用是统计指定列非 NULL 的行数。MyISAM 表对于 COUNT () 统计全表行数进行了特殊的优化，一般状况下很是快。但对于非 MyISAM 表或指定了某些 WHERE 条件，COUNT (*) 操做须要扫描大量的行才能获取精确的结果，性能也所以不佳。有时候某些业务场景并不须要彻底精确的 COUNT 值，此时能够用近似值来代替。EXPLAIN 出来的优化器估算的行数就是一个不错的近似值，执行 EXPLAIN 并不须要真正去执行查询，因此成本很低。
• Case:

SELECT c3, COUNT(*) AS accounts FROM tab where c2 < 10000 GROUP BY c3 ORDER BY num

5八、使用了合并为可空列的字符串链接

• Item: FUN.003
• Severity: L3
• Content: 在一些查询请求中，您须要强制让某一列或者某个表达式返回非 NULL 的值，从而让查询逻辑变得更简单，担心不想将这个值存下来。使用 COALESCE () 函数来构造链接的表达式，这样即便是空值列也不会使整表达式变为 NULL。
• Case:

select c1 || coalesce(' ' || c2 || ' ', ' ') || c3 as c from tbl

5九、不建议使用 SYSDATE () 函数

• Item: FUN.004
• Severity: L4
• Content: SYSDATE () 函数可能致使主从数据不一致，请使用 NOW () 函数替代 SYSDATE ()。
• Case:

SELECT SYSDATE();

60、不建议使用 COUNT (col) 或 COUNT (常量)

• Item: FUN.005
• Severity: L1
• Content: 不要使用 COUNT (col) 或 COUNT (常量) 来替代 COUNT (), COUNT () 是 SQL92 定义的标准统计行数的方法，跟数据无关，跟 NULL 和非 NULL 也无关。
• Case:

SELECT COUNT(1) FROM tbl;

6一、使用 SUM (COL) 时需注意 NPE 问题

• Item: FUN.006
• Severity: L1
• Content: 当某一列的值全是 NULL 时，COUNT (COL) 的返回结果为 0, 但 SUM (COL) 的返回结果为 NULL，所以使用 SUM () 时需注意 NPE 问题。可使用以下方式来避免 SUM 的 NPE 问题: SELECT IF (ISNULL (SUM (COL)), 0, SUM (COL)) FROM tbl
• Case:

SELECT SUM(COL) FROM tbl;

6二、不建议使用触发器

• Item: FUN.007
• Severity: L1
• Content: 触发器的执行没有反馈和日志，隐藏了实际的执行步骤，当数据库出现问题是，不能经过慢日志分析触发器的具体执行状况，不易发现问题。在 MySQL 中，触发器不能临时关闭或打开，在数据迁移或数据恢复等场景下，须要临时 drop 触发器，可能影响到生产环境。
• Case:

CREATE TRIGGER t1 AFTER INSERT ON work FOR EACH ROW INSERT INTO time VALUES(NOW());

6三、不建议使用存储过程

• Item: FUN.008
• Severity: L1
• Content: 存储过程无版本控制，配合业务的存储过程升级很难作到业务无感知。存储过程在拓展和移植上也存在问题。
• Case:

CREATE PROCEDURE simpleproc (OUT param1 INT);

6四、不建议使用自定义函数

• Item: FUN.009
• Severity: L1
• Content: 不建议使用自定义函数
• Case:

CREATE FUNCTION hello (s CHAR(20));

6五、不建议对等值查询列使用 GROUP BY

• Item: GRP.001
• Severity: L2
• Content: GROUP BY 中的列在前面的 WHERE 条件中使用了等值查询，对这样的列进行 GROUP BY 意义不大。
• Case:

select film_id, title from film where release_year='2006' group by release_year

6六、JOIN 语句混用逗号和 ANSI 模式

• Item: JOI.001
• Severity: L2
• Content: 表链接的时候混用逗号和 ANSI JOIN 不便于人类理解，而且 MySQL 不一样版本的表链接行为和优先级均有所不一样，当 MySQL 版本变化后可能会引入错误。
• Case:

select c1,c2,c3 from t1,t2 join t3 on t1.c1=t2.c1,t1.c3=t3,c1 where id>1000

6七、同一张表被链接两次

• Item: JOI.002
• Severity: L4
• Content: 相同的表在 FROM 子句中至少出现两次，能够简化为对该表的单次访问。
• Case:

select tb1.col from (tb1, tb2) join tb2 on tb1.id=tb.id where tb1.id=1

6八、OUTER JOIN 失效

• Item: JOI.003
• Severity: L4
• Content: 因为 WHERE 条件错误使得 OUTER JOIN 的外部表无数据返回，这会将查询隐式转换为 INNER JOIN 。如：select c from L left join R using (c) where L.a=5 and R.b=10。这种 SQL 逻辑上可能存在错误或程序员对 OUTER JOIN 如何工做存在误解，由于 LEFT/RIGHT JOIN 是 LEFT/RIGHT OUTER JOIN 的缩写。
• Case:

select c1,c2,c3 from t1 left outer join t2 using(c1) where t1.c2=2 and t2.c3=4

6九、不建议使用排它 JOIN

• Item: JOI.004
• Severity: L4
• Content: 只在右侧表为 NULL 的带 WHERE 子句的 LEFT OUTER JOIN 语句，有多是在 WHERE 子句中使用错误的列，如：“... FROM l LEFT OUTER JOIN r ON l.l = r.r WHERE r.z IS NULL”，这个查询正确的逻辑多是 WHERE r.r IS NULL。
• Case:

select c1,c2,c3 from t1 left outer join t2 on t1.c1=t2.c1 where t2.c2 is null

70、减小 JOIN 的数量

• Item: JOI.005
• Severity: L2
• Content: 太多的 JOIN 是复杂的裹脚布式查询的症状。考虑将复杂查询分解成许多简单的查询，并减小 JOIN 的数量。
• Case:

select bp1.p_id, b1.d_d as l, b1.b_id from b1 join bp1 on (b1.b_id = bp1.b_id) left outer join (b1 as b2 join bp2 on (b2.b_id = bp2.b_id)) on (bp1.p_id = bp2.p_id ) join bp21 on (b1.b_id = bp1.b_id) join bp31 on (b1.b_id = bp1.b_id) join bp41 on (b1.b_id = bp1.b_id) where b2.b_id = 0

7一、将嵌套查询重写为 JOIN 一般会致使更高效的执行和更有效的优化

• Item: JOI.006
• Severity: L4
• Content: 通常来讲，非嵌套子查询老是用于关联子查询，最可能是来自 FROM 子句中的一个表，这些子查询用于 ANY, ALL 和 EXISTS 的谓词。若是能够根据查询语义决定子查询最多返回一个行，那么一个不相关的子查询或来自 FROM 子句中的多个表的子查询就被压平了。
• Case:

SELECT s,p,d FROM tbl WHERE p.p_id = (SELECT s.p_id FROM tbl WHERE s.c_id = 100996 AND s.q = 1 )

7二、不建议使用联表删除或更新

• Item: JOI.007
• Severity: L4
• Content: 当须要同时删除或更新多张表时建议使用简单语句，一条 SQL 只删除或更新一张表，尽可能不要将多张表的操做在同一条语句。
• Case:

UPDATE users u LEFT JOIN hobby h ON u.id = h.uid SET u.name = 'pianoboy' WHERE h.hobby = 'piano';

7三、不要使用跨数据库的 JOIN 查询

• Item: JOI.008
• Severity: L4
• Content: 通常来讲，跨数据库的 JOIN 查询意味着查询语句跨越了两个不一样的子系统，这可能意味着系统耦合度太高或库表结构设计不合理。
• Case:

SELECT s,p,d FROM tbl WHERE p.p_id = (SELECT s.p_id FROM tbl WHERE s.c_id = 100996 AND s.q = 1 )

7四、建议使用自增列做为主键，如使用联合自增主键时请将自增键做为第一列

• Item: KEY.001
• Severity: L2
• Content: 建议使用自增列做为主键，如使用联合自增主键时请将自增键做为第一列
• Case:

create table test(id int(11) NOT NULL PRIMARY KEY (id))

7五、无主键或惟一键，没法在线变动表结构

• Item: KEY.002
• Severity: L4
• Content: 无主键或惟一键，没法在线变动表结构
• Case:

create table test(col varchar(5000))

7六、避免外键等递归关系

• Item: KEY.003
• Severity: L4
• Content: 存在递归关系的数据很常见，数据常会像树或者以层级方式组织。然而，建立一个外键约束来强制执行同一表中两列之间的关系，会致使笨拙的查询。树的每一层对应着另外一个链接。您将须要发出递归查询，以得到节点的全部后代或全部祖先。解决方案是构造一个附加的闭包表。它记录了树中全部节点间的关系，而不只仅是那些具备直接的父子关系。您也能够比较不一样层次的数据设计：闭包表，路径枚举，嵌套集。而后根据应用程序的须要选择一个。
• Case:

CREATE TABLE tab2 (p_id  BIGINT UNSIGNED NOT NULL,a_id  BIGINT UNSIGNED NOT NULL,PRIMARY KEY (p_id, a_id),FOREIGN KEY (p_id) REFERENCES tab1(p_id),FOREIGN KEY (a_id) REFERENCES tab3(a_id))

7七、提醒：请将索引属性顺序与查询对齐

• Item: KEY.004
• Severity: L0
• Content: 若是为列建立复合索引，请确保查询属性与索引属性的顺序相同，以便 DBMS 在处理查询时使用索引。若是查询和索引属性订单没有对齐，那么 DBMS 可能没法在查询处理期间使用索引。
• Case:

create index idx1 on tbl (last_name,first_name)

7八、表建的索引过多

• Item: KEY.005
• Severity: L2
• Content: 表建的索引过多
• Case:

CREATE TABLE tbl ( a int, b int, c int, KEY idx_a (a),KEY idx_b(b),KEY idx_c(c));

7九、主键中的列过多

• Item: KEY.006
• Severity: L4
• Content: 主键中的列过多
• Case:

CREATE TABLE tbl ( a int, b int, c int, PRIMARY KEY(a,b,c));

80、未指定主键或主键非 bigint

• Item: KEY.007
• Severity: L4
• Content: 未指定主键或主键非 bigint，建议将主键设置为 bigint unsigned。
• Case:

CREATE TABLE tbl (a bigint);

8一、ORDER BY 多个列但排序方向不一样时可能没法使用索引

• Item: KEY.008
• Severity: L4
• Content: 在 MySQL 8.0 以前当 ORDER BY 多个列指定的排序方向不一样时将没法使用已经创建的索引。
• Case:

SELECT * FROM tbl ORDER BY a DESC, b ASC;

8二、添加惟一索引前请注意检查数据惟一性

• Item: KEY.009

• Severity: L0

• Content: 请提早检查添加惟一索引列的数据惟一性，若是数据不惟一在线表结构调整时将有可能自动将重复列删除，这有可能致使数据丢失。

• Case:

CREATE UNIQUE INDEX part_of_name ON customer (name(10));

8三、全文索引不是银弹

• Item: KEY.010
• Severity: L0
• Content: 全文索引主要用于解决模糊查询的性能问题，但须要控制好查询的频率和并发度。同时注意调整 ft_min_word_len, ft_max_word_len, ngram_token_size 等参数。
• Case:

CREATE TABLE tb ( id int(10) unsigned NOT NULL AUTO_INCREMENT, ip varchar(255) NOT NULL DEFAULT '', PRIMARY KEY (id), FULLTEXT KEY ip (ip) ) ENGINE=InnoDB;

8四、SQL_CALC_FOUND_ROWS 效率低下

• Item: KWR.001
• Severity: L2
• Content: 由于 SQL_CALC_FOUND_ROWS 不能很好地扩展，因此可能致使性能问题；建议业务使用其余策略来替代 SQL_CALC_FOUND_ROWS 提供的计数功能，好比：分页结果展现等。
• Case:

select SQL_CALC_FOUND_ROWS col from tbl where id>1000

8五、不建议使用 MySQL 关键字作列名或表名

• Item: KWR.002
• Severity: L2
• Content: 当使用关键字作为列名或表名时程序须要对列名和表名进行转义，若是疏忽被将致使请求没法执行。
• Case:

CREATE TABLE tbl ( `select` int )

8六、不建议使用复数作列名或表名

• Item: KWR.003
• Severity: L1
• Content: 表名应该仅仅表示表里面的实体内容，不该该表示实体数量，对应于 DO 类名也是单数形式，符合表达习惯。
• Case:

CREATE TABLE tbl ( `books` int )

8七、不建议使用使用多字节编码字符 (中文) 命名

• Item: KWR.004
• Severity: L1
• Content: 为库、表、列、别名命名时建议使用英文，数字，下划线等字符，不建议使用中文或其余多字节编码字符。
• Case:

select col as 列 from tb

8八、INSERT INTO xx SELECT 加锁粒度较大请谨慎

• Item: LCK.001
• Severity: L3
• Content: INSERT INTO xx SELECT 加锁粒度较大请谨慎
• Case:

INSERT INTO tbl SELECT * FROM tbl2;

8九、请慎用 INSERT ON DUPLICATE KEY UPDATE

• Item: LCK.002
• Severity: L3
• Content: 当主键为自增键时使用 INSERT ON DUPLICATE KEY UPDATE 可能会致使主键出现大量不连续快速增加，致使主键快速溢出没法继续写入。极端状况下还有可能致使主从数据不一致。
• Case:

INSERT INTO t1(a,b,c) VALUES (1,2,3) ON DUPLICATE KEY UPDATE c=c+1;

90、用字符类型存储 IP 地址

• Item: LIT.001
• Severity: L2
• Content: 字符串字面上看起来像 IP 地址，但不是 INET_ATON () 的参数，表示数据被存储为字符而不是整数。将 IP 地址存储为整数更为有效。
• Case:

insert into tbl (IP,name) values('10.20.306.122','test')

9一、日期 / 时间未使用引号括起

• Item: LIT.002
• Severity: L4
• Content: 诸如 “WHERE col <2010-02-12” 之类的查询是有效的 SQL，但多是一个错误，由于它将被解释为 “WHERE col <1996”; 日期 / 时间文字应该加引号。
• Case:

select col1,col2 from tbl where time < 2018-01-10

9二、一列中存储一系列相关数据的集合

• Item: LIT.003
• Severity: L3
• Content: 将 ID 存储为一个列表，做为 VARCHAR/TEXT 列，这样能致使性能和数据完整性问题。查询这样的列须要使用模式匹配的表达式。使用逗号分隔的列表来作多表联结查询定位一行数据是极不优雅和耗时的。这将使验证 ID 更加困难。考虑一下，列表最多支持存放多少数据呢？将 ID 存储在一张单独的表中，代替使用多值属性，从而每一个单独的属性值均可以占据一行。这样交叉表实现了两张表之间的多对多关系。这将更好地简化查询，也更有效地验证 ID。
• Case:

select c1,c2,c3,c4 from tab1 where col_id REGEXP '[[:<:]]12[[:>:]]'

9三、请使用分号或已设定的 DELIMITER 结尾

• Item: LIT.004
• Severity: L1
• Content: USE database, SHOW DATABASES 等命令也须要使用使用分号或已设定的 DELIMITER 结尾。
• Case:

USE db

9四、非肯定性的 GROUP BY

• Item: RES.001
• Severity: L4
• Content: SQL 返回的列既不在聚合函数中也不是 GROUP BY 表达式的列中，所以这些值的结果将是非肯定性的。如：select a, b, c from tbl where foo="bar" group by a，该 SQL 返回的结果就是不肯定的。
• Case:

select c1,c2,c3 from t1 where c2='foo' group by c2

9五、未使用 ORDER BY 的 LIMIT 查询

• Item: RES.002
• Severity: L4
• Content: 没有 ORDER BY 的 LIMIT 会致使非肯定性的结果，这取决于查询执行计划。
• Case:

select col1,col2 from tbl where name=xx limit 10

9六、UPDATE/DELETE 操做使用了 LIMIT 条件

• Item: RES.003
• Severity: L4
• Content: UPDATE/DELETE 操做使用 LIMIT 条件和不添加 WHERE 条件同样危险，它可将会致使主从数据不一致或从库同步中断。
• Case:

UPDATE film SET length = 120 WHERE title = 'abc' LIMIT 1;

9七、UPDATE/DELETE 操做指定了 ORDER BY 条件

• Item: RES.004
• Severity: L4
• Content: UPDATE/DELETE 操做不要指定 ORDER BY 条件。
• Case:

UPDATE film SET length = 120 WHERE title = 'abc' ORDER BY title

9八、UPDATE 语句可能存在逻辑错误，致使数据损坏

• Item: RES.005
• Severity: L4
• Content: 在一条 UPDATE 语句中，若是要更新多个字段，字段间不能使用 AND ，而应该用逗号分隔。
• Case:

update tbl set col = 1 and cl = 2 where col=3;

9九、永远不真的比较条件

• Item: RES.006
• Severity: L4
• Content: 查询条件永远非真，若是该条件出如今 where 中可能致使查询无匹配到的结果。
• Case:

select * from tbl where 1 != 1;

100、永远为真的比较条件

Item: RES.007 Severity: L4 Content: 查询条件永远为真，可能致使 WHERE 条件失效进行全表查询。 Case:

select * from tbl where 1 = 1;

10一、不建议使用 LOAD DATA/SELECT ... INTO OUTFILE

• Item: RES.008
• Severity: L2
• Content: SELECT INTO OUTFILE 须要授予 FILE 权限，这经过会引入安全问题。LOAD DATA 虽然能够提升数据导入速度，但同时也可能致使从库同步延迟过大。
• Case:

LOAD DATA INFILE 'data.txt' INTO TABLE db2.my_table;

10二、请谨慎使用 TRUNCATE 操做

• Item: SEC.001
• Severity: L0
• Content: 通常来讲想清空一张表最快速的作法就是使用 TRUNCATE TABLE tbl_name; 语句。但 TRUNCATE 操做也并不是是毫无代价的，TRUNCATE TABLE 没法返回被删除的准确行数，若是须要返回被删除的行数建议使用 DELETE 语法。TRUNCATE 操做还会重置 AUTO_INCREMENT，若是不想重置该值建议使用 DELETE FROM tbl_name WHERE 1; 替代。TRUNCATE 操做会对数据字典添加源数据锁 (MDL)，当一次须要 TRUNCATE 不少表时会影响整个实例的全部请求，所以若是要 TRUNCATE 多个表建议用 DROP+CREATE 的方式以减小锁时长。
• Case:

TRUNCATE TABLE tbl_name

10三、不使用明文存储密码

• Item: SEC.002
• Severity: L0
• Content: 使用明文存储密码或者使用明文在网络上传递密码都是不安全的。若是攻击者可以截获您用来插入密码的 SQL 语句，他们就能直接读到密码。另外，将用户输入的字符串以明文的形式插入到纯 SQL 语句中，也会让攻击者发现它。若是您可以读取密码，黑客也能够。解决方案是使用单向哈希函数对原始密码进行加密编码。哈希是指将输入字符串转化成另外一个新的、不可识别的字符串的函数。对密码加密表达式加点随机串来防护 “字典攻击”。不要将明文密码输入到 SQL 查询语句中。在应用程序代码中计算哈希串，只在 SQL 查询中使用哈希串。
• Case:

create table test(id int,name varchar(20) not null,password varchar(200)not null)

10四、使用 DELETE/DROP/TRUNCATE 等操做时注意备份

• Item: SEC.003
• Severity: L0
• Content: 在执行高危操做以前对数据进行备份是十分有必要的。
• Case:

delete from table where col = 'condition'

10五、建议使用 datetime 替换 timestamp 类型

• Item: SKEY.005
• Severity: L4
• Content: 建议使用 datetime 替换 timestamp 类型，且默认值设置为 1970-01-01 00:00:00。 datetime 类型能保存大范围的值，从 1001 年到 9999 年，且与时区无关。使用 8 个字节的存储空间（比 timestamp 多出 4 字节）
• Case:

CREATE TABLE tbl (a datetime);

10六、缺乏数据库必须字段 last_update_time 和 is_del

• Item: SKEY.006
• Severity: L4
• Content: 数据库必须字段 （last_update_time TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT ' 最后更新时间 '; is_del TINYINT (1) UNSIGNED NOT NULL DEFAULT '0' COMMENT ' 是否删除 0：未删除 1：已删除 '）
• Case:

CREATE TABLE tbl （`last_update_time` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '最后更新时间'; `is_del` TINYINT (1) UNSIGNED NOT NULL DEFAULT '0' COMMENT '是否删除 0：未删除 1：已删除'）;

10七、last_update_time 和 is_del 类型不对

• Item: SKEY.006a
• Severity: L4
• Content: 数据库必须字段 （last_update_time TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT ' 最后更新时间 '; is_del TINYINT (1) UNSIGNED NOT NULL DEFAULT '0' COMMENT ' 是否删除 0：未删除 1：已删除 '）
• Case:

CREATE TABLE tbl （`last_update_time` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '最后更新时间'; `is_del` TINYINT (1) UNSIGNED NOT NULL DEFAULT '0' COMMENT '是否删除 0：未删除 1：已删除'）;

10八、不建议使用大字段 TEXT BLOB

• Item: SKEY.010
• Severity: L1
• Content: BLOB 和 TEXT 都是为存储很大的数据而设计的字符串数据类型，且性能开销较大，请检查是否有必要使用
• Case:

CREATE TABLE tbl （a TEXT）;

10九、整形建议使用 unsigned

• Item: SKEY.011
• Severity: L1
• Content: 请检查整形是否有负数场景，如无特殊场景，建议使用 unsigned
• Case:

CREATE TABLE tbl （a int unsigned）;

1十、'!=' 运算符是非标准的

• Item: STA.001
• Severity: L0
• Content: "<>" 才是标准 SQL 中的不等于运算符。
• Case:

select col1,col2 from tbl where type!=0

1十一、库名或表名点后建议不要加空格

• Item: STA.002
• Severity: L1
• Content: 当使用 db.table 或 table.column 格式访问表或字段时，请不要在点号后面添加空格，虽然这样语法正确。
• Case:

select col from sakila. film

1十二、索引发名不规范

• Item: STA.003
• Severity: L1
• Content: 建议普通二级索引以 idx_为前缀，惟一索引以 uniq_为前缀。
• Case:

select col from now where type!=0

11三、起名时请不要使用字母、数字和下划线以外的字符

• Item: STA.004
• Severity: L1
• Content: 以字母或下划线开头，名字只容许使用字母、数字和下划线。请统一大小写，不要使用驼峰命名法。不要在名字中出现连续下划线 '__'，这样很难辨认。
• Case:

CREATE TABLE ` abc` (a int);

11四、MySQL 对子查询的优化效果不佳

• Item: SUB.001
• Severity: L4
• Content: MySQL 将外部查询中的每一行做为依赖子查询执行子查询。 这是致使严重性能问题的常见缘由。这可能会在 MySQL 5.6 版本中获得改善，但对于 5.1 及更早版本，建议将该类查询分别重写为 JOIN 或 LEFT OUTER JOIN。
• Case:

select col1,col2,col3 from table1 where col2 in(select col from table2)

11五、若是您不在意重复的话，建议使用 UNION ALL 替代 UNION

• Item: SUB.002
• Severity: L2
• Content: 与去除重复的 UNION 不一样，UNION ALL 容许重复元组。若是您不关心重复元组，那么使用 UNION ALL 将是一个更快的选项。
• Case:

select teacher_id as id,people_name as name from t1,t2 where t1.teacher_id=t2.people_id union select student_id as id,people_name as name from t1,t2 where t1.student_id=t2.people_id

11六、考虑使用 EXISTS 而不是 DISTINCT 子查询

• Item: SUB.003
• Severity: L3
• Content: DISTINCT 关键字在对元组排序后删除重复。相反，考虑使用一个带有 EXISTS 关键字的子查询，您能够避免返回整个表。
• Case:

SELECT DISTINCT c.c_id, c.c_name FROM c,e WHERE e.c_id = c.c_id

11七、执行计划中嵌套链接深度过深

• Item: SUB.004
• Severity: L3
• Content: MySQL 对子查询的优化效果不佳，MySQL 将外部查询中的每一行做为依赖子查询执行子查询。 这是致使严重性能问题的常见缘由。
• Case:

SELECT * from tb where id in (select id from (select id from tb))

11八、子查询不支持 LIMIT

• Item: SUB.005
• Severity: L8
• Content: 当前 MySQL 版本不支持在子查询中进行 'LIMIT & IN/ALL/ANY/SOME'。
• Case:

SELECT * FROM staff WHERE name IN (SELECT NAME FROM customer ORDER BY name LIMIT 1)

11九、不建议在子查询中使用函数

• Item: SUB.006
• Severity: L2
• Content: MySQL 将外部查询中的每一行做为依赖子查询执行子查询，若是在子查询中使用函数，即便是 semi-join 也很难进行高效的查询。能够将子查询重写为 OUTER JOIN 语句并用链接条件对数据进行过滤。
• Case:

SELECT * FROM staff WHERE name IN (SELECT max(NAME) FROM customer)

120、不建议使用分区表

• Item: TBL.001
• Severity: L4
• Content: 不建议使用分区表
• Case:

CREATE TABLE trb3(id INT, name VARCHAR(50), purchased DATE) PARTITION BY RANGE(YEAR(purchased)) (PARTITION p0 VALUES LESS THAN (1990), PARTITION p1 VALUES LESS THAN (1995), PARTITION p2 VALUES LESS THAN (2000), PARTITION p3 VALUES LESS THAN (2005) );

12一、请为表选择合适的存储引擎

• Item: TBL.002
• Severity: L4
• Content: 建表或修改表的存储引擎时建议使用推荐的存储引擎，如：innodb
• Case:

create table test(`id` int(11) NOT NULL AUTO_INCREMENT)

12二、以 DUAL 命名的表在数据库中有特殊含义

• Item: TBL.003
• Severity: L8
• Content: DUAL 表为虚拟表，不须要建立便可使用，也不建议服务以 DUAL 命名表。
• Case:

create table dual(id int, primary key (id));

12三、表的初始 AUTO_INCREMENT 值不为 0

• Item: TBL.004
• Severity: L2
• Content: AUTO_INCREMENT 不为 0 会致使数据空洞。
• Case:

CREATE TABLE tbl (a int) AUTO_INCREMENT = 10;

12四、请使用推荐的字符集

• Item: TBL.005
• Severity: L4
• Content: 表字符集只容许设置为 utf8mb4
• Case:

CREATE TABLE tbl (a int) DEFAULT CHARSET = latin1;

12五、不建议使用视图

• Item: TBL.006
• Severity: L1
• Content: 不建议使用视图
• Case:

create view v_today (today) AS SELECT CURRENT_DATE;

12六、不建议使用临时表

• Item: TBL.007
• Severity: L1
• Content: 不建议使用临时表
• Case:

CREATE TEMPORARY TABLE `work` (`time` time DEFAULT NULL) ENGINE=InnoDB;