基础
MySQL
MySQL
  • 基础知识
    • MySQL 的安装与配置
      • Windows
        • 安装
        • 配置文件
      • Linux
        • 安装
        • 配置文件
      • docker
      • mysql 配置文件格式
    • MySQL 查询的执行过程
      • MySQL 的客户端/服务器通信协议
      • MySQL 查询优化器
        • 优化器可能选择错误的执行计划
        • MySQL 能够处理的优化类型
          • 优化 COUNT()、MIN() 和 MAX()
          • 预估并转化为常数表达式
          • 提前终止查询
          • 排序优化
      • MySQL如何执行联接查询
    • 事务
      • ACID
      • 隔离级别
      • 死锁
      • 事务日志
      • 两阶段锁定协议
      • 多版本并发控制(MVCC)
  • SQL 优化
    • schema 设计
      • 选择数据类型
        • 整数类型
        • 实数类型
        • 字符串类型
          • VARCHAR 和 CHAR
          • BINARY 和 VARBINARY
          • BLOB 和 TEXT
          • ENUM 和 SET
        • 日期类型
      • 选择标识符
    • 索引
      • HASH 索引
      • B-tree 索引
      • 聚簇索引
      • 覆盖索引
      • 前缀索引和索引的选择性
      • 索引合并
      • 选择合适的索引列顺序
      • 使用索引扫描来做排序
      • 维护索引和表
    • 查询优化
      • 优化 SQL 语句的一般步骤
        • 1. 通过 show status 命令了解各种 SQL 的执行频率
        • 2. 定位执行效率较低的 SQL 语句
        • 3. 通过 EXPLAIN 分析低效 SQL 的执行计划
        • 4. 通过 SHOW PROFILE 分析 SQL
        • 5. 通过 TRACE 分析优化器如何选择执行计划
        • 6. 确定问题并采取相应的优化措施
      • 两个简单实用的优化方法
      • 一个复杂查询还是多个简单查询
      • 常用 SQL 的优化
        • 大批量插入数据
        • 优化 GROUP BY 语句
        • 优化联接查询
        • 优化分页查询
        • 优化 SQL_CALC_FOUND_ROWS
        • 优化 UNION 查询
    • Performance Schema
      • 配置
      • 使用
        • 检查SQL语句
        • 检查预处理语句
        • 语句剖析
        • 检查读写性能
        • 检查内存使用情况
        • 检查变量
    • MySQL线程
    • 复制
      • 概述
        • 复制中的各类文件
        • 三种复制格式
        • 全局事务标识符(GTID)
        • 崩溃后的复制安全
      • 安装
        • 基于二进制日志文件位置的复制
        • 基于GTID的复制
      • 复制拓扑
        • 主动/被动模式
        • 主动/只读池模式
        • 多级复制架构
  • 其他
    • 查询缓存
    • 批量insert
    • MySQL 锁的类型
    • MySQL 的索引有哪些
    • INSERT ... ON DUPLICATE KEY UPDATE Statement
由 GitBook 提供支持
在本页
  • 重要性
  • 遵循的原则
  1. SQL 优化
  2. schema 设计

选择标识符

上一页日期类型下一页索引

最后更新于8个月前

一般来说,标识符是引用行及通常使其唯一的方式。例如,如果你有一个关于用户的表,可能希望为每个用户分配一个数字 ID 或唯一的用户名,此字段可能是主键中的部分或全部。

重要性

为标识符列选择合适的数据类型非常重要:

  • 与其他列相比,更有可能将标识符列与其他值(例如,在联接中)进行比较,并使用它们进行查找。

  • 标识符列也可能在其他表中作为外键,因此为标识符列选择数据类型时,应该与联接表中的对应列保持一致。

遵循的原则

进行标识符选择的时候应该遵循以下原则:

  1. 在为标识符列选择类型时,不仅需要考虑存储类型,还需要考虑 MySQL 如何对该类型执行计算和比较。例如,MySQL 在内部将 类型存储为整数,但在字符串上下文中进行比较时,会将它们转换为字符串。

  2. 选择类型后,要确保在所有相关表中使用相同的类型。类型应该完全匹配,包括 UNSIGNED 等属性。混合不同的数据类型可能导致性能问题,即使没有性能影响,在进行比较操作时,隐式类型转换也可能会产生难以发现的错误。甚至在很久以后,当你忘记正在比较不同类型的数据时,这些问题可能会突然出现。

  3. 在可以满足值的范围的需求,并且预留未来增长空间的前提下,应该选择最小的数据类型。

  4. 整数通常是标识符的最佳选择,因为它们速度快,并且可以自动递增。AUTO_INCREMENT 是一个列属性,可以为新的行自动生成一个整数类型的值。

  5. 如果使用 ENUM 字段来定义类型,可能会设计一张以这个 ENUM 字段为主键的查找表。(可以在查找表中添加描述性文本的列,以生成术语表,或者在网站上的下拉菜单中提供有意义的标签。)在这种情况下,使用 ENUM 类型作为标识符是可行的,但是大部分情况下都要避免这么做。

  6. 如果可能,应避免使用字符串类型作为标识符的数据类型,因为它们很消耗空间,而且通常比整数类型慢。

注意

对于完全“随机”的字符串要非常小心,如 MD5()、SHA1() 或 UUID() 生成的字符串。这些函数生成的新值会任意分布在很大的空间内,这会减慢 INSERT 和某些类型的 SELECT 查询的速度,因为:

  • 插入的值会写到索引的随机位置,所以会使得 INSERT 查询变慢。这会导致页分裂、磁盘随机访问,以及对于聚簇存储引擎产生聚簇索引碎片。

  • SELECT 查询也会变慢,因为逻辑上相邻的行会广泛分布在磁盘和内存中。

  • 对于所有类型的查询,随机值都会导致缓存的性能低下,因为它们会破坏引用的局部性,而这正是缓存的工作原理。如果整个数据集都是“热的”,那么将任何特定部分的数据缓存到内存中都没有任何好处,而且如果工作集比内存大,缓存就会出现大量刷新和不命中。

如果存储通用唯一标识符(UUID)值,则应该删除破折号,或者更好的做法是,使用 UNHEX() 函数将 UUID 值转换为 16 字节的数字,并将其存储在一个 BINARY(16) 列中。可以使用 HEX() 函数以十六进制格式检索值。

ENUM 和 SET