2.使用字符变长字段，不要使用char
3、对于二进制多媒体数据、管道数据（如日志）、非常大的文本数据，不要放在数据库字段中。
尽量避免对WHERE子句中的字段进行函数或表达式操作，这会导致引擎放弃使用索引而进行全表扫描。 喜欢：
* FROM T1 WHERE F1/2=100 应更改为： * FROM T1 WHERE F1=100*2
9.避免使用!=或<>、IS NULL或IS NOT NULL、IN、NOT IN等运算符。
因为这样会导致系统无法使用索引，只能直接查找表中的数据。 例如： id FROM WHERE id != "B%" 优化器将无法确定它将通过索引命中的行数，因此需要搜索表的所有行。 如果它可以被 in 语句中的语句替换，请使用它。
10. 将列设置为 NOT NULL
允许NULL的列不仅会占用更多的磁盘空间，而且会影响查询分析器对SQL语句的优化。 当业务场景允许的情况下，首先应该将该列设置为NOT NULL，并给它一个默认值，如空白字符串、-1等。
11.优先设置索引唯一
如果已知某列的内容不会有重复的行，并且需要创建索引，则应该创建唯一索引。 除了防止误操作之外，还可以明确告知查询分析器，只要找到符合条件的记录，某些查询就会成功。 是时候结束扫描了。
12. 索引不会包含具有 NULL 值的列。
只要列包含 NULL 值，它就不会包含在索引中。 只要复合索引中的一列包含NULL值，那么该列对于复合索引无效。 因此，在设计数据库时，我们不应该让字段的默认值为NULL。
13.使用哈希索引
如果您要对很长的字符串列进行精确搜索，直接构建索引可能不是最好的方法。 这会导致占用更多的磁盘空间并降低索引效率，比如这个查询。
url 来自 url='';
可以考虑从应用层面进行优化，在表中添加一个int列。 插入记录时，通过一定的哈希算法计算出URL的哈希值，记录在列中，并在列上创建索引。
查询语句修改为：
url 来自 where = 和 url='';
通过的索引会过滤掉大部分不满足条件的行，后续的精确匹配解决了哈希冲突问题。
14.避免类型转换
这里所说的“类型转换”是指当where子句中字段的类型与传入的参数类型不一致时发生的类型转换：
转换是通过转换函数人为完成的
这直接导致MySQL（其实其他数据库也会有同样的问题）无法使用索引。 如果一定要转换，应该在传入的参数上进行转换。
数据库自行执行转换
如果我们传入的数据类型与字段类型不一致，并且我们没有做任何类型转换处理，MySQL可能会对我们的数据本身进行类型转换操作，也可能不进行处理而交给存储引擎进行处理加工。 这样，以后就会出现索引无法使用的情况，导致执行计划出现问题。
15.尝试使用union all而不是union。
union 和 union all 的主要区别在于，前者需要合并两个（或多个）结果集，然后再执行唯一的过滤操作，这会涉及排序，增加大量 CPU 操作，增加资源消耗和延迟。 因此，当我们可以确认不可能出现重复的结果集或者我们不关心重复的结果集时，请尝试使用 union all 而不是 union。
16. 尽可能少或尽可能
当where子句中存在多个“or”条件并存时，MySQL的优化器并不能很好地解决执行计划优化问题。 另外，MySQL独特的SQL和分层架构导致性能不佳。 算是比较低调的了。 很多情况下，使用 union all 或 union（必要时）代替“或”会得到更好的结果。
17.使用连接（JOIN）代替子查询（Sub-）
MySQL从4.1开始支持SQL子查询。 该技术可以使用语句创建单列查询结果，然后将此结果用作另一个查询中的过滤条件。 例如，如果我们要删除基本客户信息表中没有任何订单的客户，我们可以使用子查询先从销售信息表中检索所有发出订单的客户的ID，然后将结果传递给主查询，如下图：
来自何处，不在（来自）
使用子查询可以完成许多逻辑上需要多个步骤才能一次性完成的 SQL 操作。 它还可以避免事务或表锁，而且也很容易编写。 然而，在某些情况下，子查询可以被更高效的连接（JOIN）所取代。例如，假设我们要检索所有没有订单记录的用户，我们可以使用以下查询来完成：
* 来自何处不在 ( FROM )
如果使用连接（JOIN）..来完成这个查询，速度会快很多。 特别是如果表中有索引的话，性能会更好。 查询如下：
* 从
左连接.=。
在哪里。 一片空白
连接（JOIN）..之所以效率更高，是因为MySQL不需要在内存中创建临时表来完成这个逻辑上的两步查询。
18. 两个表之间进行关联的正确方法
as us 左连接 as tas
在我们身上。=tas.pk_id
SET us.birth=tas。
发表评论:
◎欢迎参与讨论，请在这里发表您的看法、交流您的观点。