大家好，我是讯享网，很高兴认识大家。



 <svg xmlns="http://www.w3.org/2000/svg" style="display: none;"> <path stroke-linecap="round" d="M5,0 0,2.5 5,5z" id="raphael-marker-block" style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0);"></path> </svg> 

讯享网

1. 选择合适的字段类型

设计表时，尽量选择存储空间小的字段类型：

• 整型字段：从、、到。
• 小数类型：对于金额等需精确计算的数值使用，避免使用和。
• 字符串：根据实际长度选择（定长）或（变长）。不宜超过5000字符；长度需求大的数据建议使用，并将大字段拆分到单独的表中

2. 确定字段的合理长度

字段长度表示字符数或字节数，例如适用于用户名字段（通常为5到20个字符）。建议字段长度设为2的幂，如32、64、128等。

3. 控制表的字段数量

一张表的字段数量尽量控制在20个以内，以避免数据量过大导致查询效率低。如果字段较多，建议分拆为多张表。

4. 尽量定义字段为 NOT NULL

为防止空指针问题，并提升查询性能，除非有特殊需求，字段都应定义为，可以通过默认值或常量来填充字段。

5. 使用数值类型代替字符串

数值类型占用存储空间小、比较速度更快。

例子： 性别字段建议用数值（如0代表女生，1代表男生）而非字符串（如“WOMEN”、“MAN”）。

6. 评估并添加必要的索引

根据表的数据量和查询需求设置索引：

• 索引数量不宜过多（单表索引个数不超过5个）。
• 区分度低的字段（如性别）不适合建立索引。
• 可通过联合索引优化多列条件查询。
• 定期分析和优化索引

  讯享网

7. 避免使用MySQL保留字

避免库名、表名或字段名使用的保留字（如、等），否则需要使用反引号引用，会增加代码复杂性。

8. 统一字符集的选择

字符集推荐使用或以支持中英文及。其他字符集如仅适合中文环境，适合仅支持英文的场景。

9. 数据冗余

在某些场景下，适当的数据冗余可以提高查询效率，例如在读多写少的应用中。

10. 使用分区表

对于大数据量的表，使用分区表可以提高查询性能。

示例：

• 范围分区（Range Partitioning）：
  • 根据某个字段的值范围进行分区。适用于时间戳、日期等有序字段。

• 列表分区（List Partitioning）：
  • 根据某个字段的特定值列表进行分区。适用于类别、地区等离散字段。

  讯享网

• 哈希分区（Hash Partitioning）：
  • 根据某个字段的哈希值进行分区。适用于均匀分布的数据。

• 复合分区（Composite Partitioning）：
  • 结合多种分区策略，先按一种策略分区，再在每个子分区中按另一种策略分区。适用于复杂的数据分布。

  讯享网

1. 使用 EXPLAIN 分析查询计划

可以帮助你了解查询的执行计划，找出潜在的性能瓶颈。

例子：

2. 使用 PARTITION PRUNING 优化分区表查询

可以显著提高分区表的查询性能，因为它可以跳过不需要的分区。

例子：

讯享网

3. 使用 EXPLAIN ANALYZE 深入分析查询性能

可以提供详细的查询执行计划和实际执行时间，帮助你更好地优化查询。

例子：

4. 使用 OPTIMIZE TABLE 优化表性能

可以回收未使用的空间，提高表的性能。

讯享网

5. 使用 ANALYZE TABLE 更新统计信息

可以更新表的统计信息，帮助优化器生成更高效的查询计划。

例子：

1. 避免使用 SELECT *，使用具体字段

反例：

讯享网

正例：

原因： 使用具体字段可以节省资源、减少网络开销，且能避免回表查询。

2. 避免在 WHERE 子句中使用 OR

反例：

讯享网

正例：

原因：当 操作符连接的条件涉及多个列时，数据库优化器可能无法有效地使用索引。特别是当这些列上有不同的索引时，优化器可能无法选择最优的索引组合。

3. 避免在 WHERE 子句中使用函数

反例：

讯享网

正例：

原因： 在 子句中使用函数会导致索引失效。

4. 避免在 WHERE 子句中对字段进行表达式操作

反例：

讯享网

正例：

原因 : 表达式操作会增加额外的计算开销。数据库引擎需要对每一行数据进行表达式计算，然后再进行过滤，这会显著增加查询的执行时间。

5. 使用 LIMIT 避免不必要的数据返回

反例：

讯享网

正例：

原因： 提升查询效率，避免多余的数据返回。

6. 批量操作（插入、删除、查询）

反例：

讯享网

正例：

原因： 批量插入性能更优。

7. 使用 UNION ALL 替换 UNION（无重复记录时）

反例：

讯享网

正例：

原因： 会排序和合并， 则省去这一步。

8. 避免在索引列上使用内置函数

反例：

讯享网

正例：

原因： 索引列上使用函数会导致索引失效。

9. 在 GROUP BY 前进行条件过滤

反例：

讯享网

正例：

10. 优化 LIKE 语句

反例：

讯享网

正例：

原因： 放在前面会导致索引失效。

讯享网

11. 使用小表驱动大表

例子： 假设我们有个客户表和一个订单表。其中订单表有10万记录，客户表只有1000行记录。现在要查询下单过的客户信息，可以这样写：

正例：

讯享网

使用 实现：

原因： 会逐行扫描 表（即小表），对每一行 ，在 表（大表）中检查是否有 的记录。

12. IN 查询的元素不宜太多

反例：

讯享网

正例： 分批进行，比如每批200个：

原因： 如果 后面的元素过多，即使后面的条件加了索引，还是会影响性能。

13. 优化 LIMIT 分页

反例：

讯享网

正例： 使用标签记录法：

延迟关联法：

讯享网

14. 避免返回过多数据量

反例：

正例：

讯享网

原因：

• 查询效率： 当返回的数据量过大时，查询所需的时间会显著增加，导致数据库性能下降。
• 网络传输： 大量数据的传输会占用网络带宽，可能导致网络拥堵和延迟。
• 减少返回的数据量可以降低网络传输的负担，提高数据传输效率。

15. 优先使用连接查询而非子查询

反例：

正例：

讯享网

原因： 使用子查询可能会创建临时表。

16. INNER JOIN、LEFT JOIN、RIGHT JOIN，优先使用 INNER JOIN，如果是 LEFT JOIN，左边表结果尽量小

反例：

正例：

讯享网

原因： 如果 是等值连接，返回的行数可能较少，性能更好。使用 时，左边表数据结果尽量小，条件尽量放在左边处理。

17. 避免 != 或 <> 操作符

反例：

正例： 分为两个查询：

讯享网

原因： 某些情况下，使用 或 操作符可能导致索引失效，从而影响查询性能。这是因为 和 操作符通常会导致数据库引擎无法高效地利用索引。

18. 使用联合索引时遵循最左匹配原则

例子： 联合索引 ，查询 和 时优先使用 。

表结构：

反例：

讯享网

正例：

正例：

讯享网

原因： 使用联合索引时遵循最左匹配原则是非常重要的，这有助于数据库引擎高效地利用索引，从而提高查询性能。最左匹配原则意味着在查询条件中，从联合索引的最左边开始匹配索引列，直到遇到不匹配的列为止。

19. 对 WHERE 和 ORDER BY 涉及的列建索引

反例：

正例：

讯享网

20. 使用覆盖索引

正例：

21. 删除冗余索引

反例：

讯享网

正例：

原因： 重复的索引需要维护，并且优化器在优化查询的时候也需要逐个地进行考虑，这会影响性能。

22. 使用 INDEX HINTS 强制使用特定索引

例子：

讯享网

原因： 在某些情况下，优化器可能选择错误的索引，使用 可以强制使用特定索引。

23. 使用 FULLTEXT 索引进行全文搜索

例子：

原因： 索引可以提高全文搜索的性能。

24. 避免在 ORDER BY 子句中使用表达式

反例：

讯享网

正例：

原因： 在 子句中使用表达式会导致索引失效。

25. 避免超过3个以上的表连接

原因： 连接表越多，编译的时间和开销也就越大。把连接表拆开成较小的几个执行，可读性更高。

26. 使用 CASE 语句替代复杂的 IF 条件

例子：

讯享网

原因： 语句可以使逻辑更清晰，提高可读性和维护性。

27. 使用 WITH 子句（Common Table Expressions, CTE）

例子：

原因： 可以使查询结构更清晰，便于理解和维护。

28. 避免使用 DISTINCT 除非必要

反例：

讯享网

正例：

原因： 会进行额外的排序和去重操作，影响性能。如果只需要去重，可以使用 。

29. 使用 PARTITION PRUNING 优化分区表查询

例子：

讯享网

原因： 可以显著提高分区表的查询性能，因为它可以跳过不需要的分区。

1. 合理利用视图（View）进行复杂查询

正例：

2. 使用表分区（Partitioning）优化大表性能

正例：

讯享网

3. 合理使用存储过程（Stored Procedure）来减少多次 SQL 交互

正例：

4. 使用临时表（Temporary Tables）处理复杂查询

正例：

讯享网

原因： 临时表可以在处理复杂查询时提高性能，特别是在多次使用相同子查询结果的情况下。

5. 使用适当的隔离级别

原因： 在高并发环境中选择适当的事务隔离级别（如 ），可以避免不必要的锁竞争和阻塞，提升并发效率。

6. 避免在事务中执行非必要的操作

原因： 在事务中应避免执行耗时操作，比如网络请求或复杂计算，以减少锁的持有时间。优先确保事务操作集中在必要的数据变更上。

7. 使用批量更新或删除

正例：