优化数据库结构

优化数据大小

→ 减少磁盘写入和读取的数据量

→ 在查询执行期间主动处理其内容时主内存较少

→ 产生更小的索引，可以更快地处理

表格列

• 尽可能使用最有效（最小）的数据类型
• 如果可能，将列声明为 NOT NULL → 更好地使用索引并消除测试每个值是否为 NULL 的开销。

索引

• 表的主索引应尽可能短
• 仅创建提高查询性能所需的索引。索引有利于检索，但会减慢插入和更新操作。
• 搜索列的组合→创建复合索引
• 索引中的第一列应该是重复最多的列→以获得更好的索引压缩。

连接

• 在具有相同数据类型的不同表中声明具有相同信息的列→相同数据类型
• 保持列名简单，

正常化

• 通常情况下，尽量保持所有数据不冗余
• 如果速度比磁盘空间和保留多个数据副本的维护成本更重要

优化数据类型

• 对于可以表示为字符串或数字的唯一 ID 或其他值，→ 数字值可以比相应的字符串以更少的字节存储，传输和比较它们速度更快，占用的内存更少。
• 比较不同列中的值时，尽可能声明具有相同字符集和排序规则的列 → 避免字符串转换
• 对于大小小于 8KB 的列值，请使用二进制 VARCHAR 而不是 BLOB。 GROUP BY 和 ORDER BY 子句可以生成临时表，如果原始表不包含任何 BLOB 列，这些临时表可以使用 MEMORY 存储引擎。
• 如果一个表包含字符串列并且不经常访问→拆分到另一个表并连接→当MySQL从一行中检索任何值时，它会读取包含该行所有列（可能还有其他相邻行）的数据块。保持每行较小，仅包含最常用的列，可以让每个数据块容纳更多行。
• 当您使用随机生成的值作为 InnoDB 表中的主键时，请在其前面添加一个升序值（例如当前日期和时间）（如果可能）。
• 对于具有多个列的表，为了减少不使用 BLOB 列的查询的内存需求，请考虑将 BLOB 列拆分为单独的表，并在需要时使用联接查询引用它
• • 由于检索和显示 BLOB 值的性能要求可能与其他数据类型有很大不同，因此您可以将 BLOB 特定表 放在不同的存储设备上，甚至是 单独的存储设备上数据库实例。例如，要检索 BLOB 可能需要大量顺序磁盘读取，这比 SSD 设备更适合传统硬盘驱动器。
• 您可以将列值的哈希值存储在单独的列中，对该列建立索引，然后在查询中测试哈希值，而不是测试非常长的文本字符串是否相等。 （使用 MD5() 或 CRC32() 函数生成哈希值。）

优化SQL语句

我们发现分两步分析性能不佳的查询很有用：

• 了解您的应用程序检索的数据是否超出您的需要。这通常意味着它访问了太多行，但也可能访问了太多列。
• 查明MySQL 服务器 分析的行数是否超出其需要。

优化 SELECT 语句

• 避免在谓词中使用函数
• 避免在谓词开头使用通配符 (%)
• 仅在必要时使用 DISTINCT 和 UNION