分库分表后不能用自增主键，因其在各分片独立生成导致ID重复、无法获取全局唯一ID、中间件支持差、扩容易冲突、不支持范围查询；推荐使用雪花算法ID、有序UUID或业务发号器。
分库分表后自增主键为什么一定不能用
分库分表环境下，AUTO_INCREMENT 主键在每个分片独立生成，必然导致跨分片重复——比如两个分片同时插入 id = 1，逻辑上属于同一张表，违反主键唯一性约束。线上常见报错就是 Duplicate entry '1' for key 'PRIMARY'。
更隐蔽的问题是：即使没报错，业务层也拿不到写入后的 ID（last_insert_id() 只返回本分片的值），无法做后续关联或幂等控制。中间件如 ShardingSphere 对自增主键的支持也极其有限，多数场景直接禁用。
- 每个分片的
AUTO_INCREMENT起始值、步长若未统一配置，冲突概率更高 - 扩容新增分片时，旧数据无法保证与新分片 ID 不重叠
- 无法支持按主键范围查询（如
id BETWEEN 1000 AND 2000），因为 ID 不连续、不全局有序
什么主键类型真正适合分库分表
核心要求就两条：全局唯一 + 写入局部性好。满足这两点的主流方案只有三类，且优先级明确：
-
雪花算法（Snowflake）ID：64 位整数，含时间戳、机器 ID、序列号，趋势递增、无碰撞、体积小（8 字节）。MySQL 中用
BIGINT UNSIGNED存储，二级索引开销最小 - 有序 UUID（如 UUID v7 或 ULID）：比雪花稍长（16–24 字节），但兼容性更好；避免传统 UUID v4 的完全随机问题，保留时间序，减少页分裂
- 业务发号器（如 Leaf、TinyID）：适合对 ID 生成延迟敏感或需定制规则（如带业务前缀）的场景；但引入额外服务依赖，运维成本上升
不推荐：UUID v4（32 字符字符串）、MD5/SHA1 哈希值、纯时间戳——它们要么太长、要么无序、要么易冲突。
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
主键和分片键的关系必须理清
主键 ≠ 分片键，但二者设计必须协同。典型错误是把 user_id 当分片键，又把 order_id（雪花 ID）当主键，结果所有按 order_id 查询都变成全分片广播。
- 如果高频查询确实以主键为条件（如订单详情页查
order_id），那主键最好能参与路由——例如把雪花 ID 的高位时间戳部分作为分片键的一部分（需中间件支持） - 更现实的做法是：主键只负责唯一标识，
WHERE条件中必须带分片键（如user_id）才能走单分片；否则必须接受广播代价 - 不要试图用联合主键（如
(user_id, order_id)）替代全局主键——它无法解决跨user_id查询问题，且破坏主键语义（主键应标识行，不是路由组合）
二级索引字段选主键还是业务字段
二级索引的叶子节点存储的是主键值，不是行指针。这意味着：主键越长，二级索引越大，缓存命中率越低。
举例：用 CHAR(36) 存 UUID v4，一个二级索引节点只能存约 1/4 的条目数，相比 BIGINT 主键，同样内存下要多读 3–4 次磁盘页。
- 高频查询字段（如
email、phone）建二级索引没问题，但别让它成为主键 - 如果业务强依赖某业务字段唯一性（如
trade_no），可设为唯一索引，但主键仍用雪花 ID —— 两者不冲突 - 避免在二级索引里包含冗余字段“覆盖索引”来规避回表，除非该查询频次极高且字段极少；否则主键本身已是聚簇索引，回表成本可控
真正容易被忽略的是：分库分表后，每个分片的二级索引只覆盖本分片数据，统计信息不准、执行计划易误判，所以 EXPLAIN 看到的“走索引”未必真快——务必在真实分片规模下压测验证。
