基础
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 提供支持
在本页
  • VARCHAR
  • CHAR
  1. SQL 优化
  2. schema 设计
  3. 选择数据类型
  4. 字符串类型

VARCHAR 和 CHAR

VARCHAR 和 CHAR 是两种最主要的字符串类型。

每个字符串列可以有自己的字符集和该字符集的排序规则集。

存储引擎在内存中存储 CHAR 或 VARCHAR 值的方式可能与在磁盘上存储该值的方式不同,并且服务器在从存储引擎检索该值时可能会将其转换为另一种存储格式。

VARCHAR

VARCHAR 用于存储可变长度的字符串,是最常见的字符串数据类型。它比固定长度的类型更节省空间,因为它仅使用必要的空间。

VARCHAR 需要额外使用 1 或 2 字节记录字符串的长度:

  • 如果列的最大长度小于或等于 255 字节,则只使用 1 字节表示

  • 否则使用 2 字节

假设采用 latin1 字符集,一个 VARCHAR(10) 的列需要 11 字节的存储空间。VARCHAR(1000) 的列则需要 1002 个字节,因为需要 2 字节存储长度信息。

VARCHAR 节省了存储空间,所以对性能也有帮助。但是,由于行是可变长度的,在更新时可能会增长,这会导致额外的工作。如果行的增长使得原位置无法容纳更多内容,则处理行为取决于所使用的存储引擎。例如,InnoDB 可能需要分割页面来容纳行。

下面这些情况使用 VARCHAR 是合适的:

  • 字符串列的最大长度远大于平均长度;

  • 列的更新很少,所以碎片不是问题;

  • 使用了像 UTF-8 这样复杂的字符集,每个字符都使用不同的字节数进行存储。

慷慨是不明智的!

使用 VARCHAR(5) 和 VARCHAR(200) 存储 'hello' 的空间开销是一样的,那么使用更短的列有什么优势吗?

较大的列会使用更多的内存,因为 MySQL 通常会在内部分配固定大小的内存块来保存值。这对于使用内存临时表的排序操作来说尤其糟糕。在利用磁盘临时表进行文件排序时也同样糟糕。

最好的策略是只分配真正需要的空间。

CHAR

CHAR 是固定长度的:MySQL 总是为定义的字符串分配足够的空间。

  • CHAR 适合存储非常短的字符串,或者适用于所有值的长度都几乎相同的情况。

    例如,对于用户密码的MD5 值,CHAR 是一个很好的选择,它们的长度总是相同的。

  • 对于经常修改的数据,CHAR 也比 VARCHAR 更好,因为固定长度的行不容易出现碎片。

  • 对于非常短的列,CHAR 也比 VARCHAR 更高效。

    例如,设计为只保存 Y 和 N 的值的 CHAR(1) 在单字节字符集中只使用 1 字节,但 VARCHAR(1) 需要 2 字节,因为还有一个记录长度的额外字节。

当存储 CHAR 值时,MySQL 删除所有尾随空格。如果需要进行比较,值会用空格填充。

-- 数据准备
CREATE TABLE char_test
(
    char_col CHAR(10)
);
INSERT INTO char_test
VALUES ("string1"),
       ("   string2"),
       ("string3   "),
       (" string4 ");

-- 测试:尾部的空格被删除
SELECT CONCAT("'", char_col, "'")
FROM char_test;
+--------------------------+
|concat("'", char_col, "'")|
+--------------------------+
|'string1'                 |
|'   string2'              |
|'string3'                 |
|' string4'                |
+--------------------------+
上一页字符串类型下一页BINARY 和 VARBINARY

最后更新于8个月前