DevCN开发者的创作与交流社区
RSS
菜单
社区成员个人主页
阿成员
DEV CN / 成员主页

阿青 · 社区话题账号

查看阿青 · 社区话题账号发布的技术文章、关注圈子与公开讨论。

0技术文章4关注圈子458圈内发布1关注者
登录后关注登录后私信
COMMUNITY POSTS

交流圈发布内容

作者在不同技术圈子中的观点与讨论

1
# MySQL

MySQL 主键怎么设计？自增、UUID、雪花怎么选？

自增 BIGINT：插入有序（B+ 树顺序写、页不分裂）、空间小、简单——单库首选；缺点：分布式多写会冲突、可被遍历（安全敏感注意）、迁移合并麻烦。UUID：全局唯一、无中心——但 36 字符（可用 BINARY(16)/UUID_TO_BIN 优化）、无序导致随机 IO 与页分裂、索引性能差。雪花（Snowflake）：趋势递增、全局唯一、高性能——分布式场景推荐（分库分表、多机房）。实践：单库用自增 BIGINT；分库分表/分布式用…

2
# MySQL

MySQL 数据库三大范式是什么？什么时候可以反范式？

第一范式（1NF）：列原子性，每列不可再分；第二范式（2NF）：1NF + 非主键列完全依赖主键（消除部分依赖，适合联合主键）；第三范式（3NF）：2NF + 非主键列不传递依赖主键（消除冗余，如订单表不存客户地址，通过 customer_id 关联）。反范式：有意冗余（如订单表冗余商品名称、客户名）换取性能——减少 JOIN、加速查询。适用：读多写少、查询性能敏感、JOIN 昂贵（分库分表后无法 JOIN）；代价：冗余一致性维护（应用…

3
# MySQL

MySQL 冷热数据分离怎么设计？

冷热分离：按访问频率把数据分层存储（热数据高 IO、冷数据低成本），降低存储成本、提升热数据性能。实现：① 时间维度：订单/日志按时间归档（如 90 天前转归档库/表，用定时任务 + pt-archiver 迁移）；② 访问维度：历史低频数据进冷库（TiDB/对象存储/数据仓库）；③ 设计要点：应用读路径兼容（归档前查询走热表，之后走归档接口/冷库）；④ 归档任务对生产影响小（分批、限速）；⑤ 冷数据仍可查询（提供归档查询接口或数据仓库…

4
# MySQL

MySQL 分布式事务有哪些方案？怎么选？

① XA 两阶段提交（2PC）：数据库原生支持（prepare/commit），强一致但性能差、阻塞；② TCC（Try-Confirm-Cancel）：业务补偿，最终一致、性能好，实现复杂（需写三套逻辑）；③ 本地消息表：本地事务写业务+消息表，异步投递，最终一致，简单可靠；④ MQ 事务消息（RocketMQ 半消息）：本地事务与消息投递原子，异步解耦；⑤ Saga：长事务拆子事务+补偿，适合流程长场景；⑥ Seata（阿里）：AT…

5
# MySQL

MySQL 分库分表后跨分片查询和聚合怎么解决？

跨分片难题：① 跨分片 JOIN：不跨分片设计（冗余字段/宽表）、应用层组装（分片分别查再合并）、中间件支持部分（ShardingSphere 绑定表/广播表）；② 跨分片聚合（COUNT/SUM/分页排序）：中间件聚合（会合并多分片结果，深分页性能差）；③ 全局查询：遍历所有分片合并（广播）——只适合低频管理查询；④ 方案：按业务设计避免（查询条件尽量带分片键）、汇总表/宽表冗余、ES 索引做搜索、分片内分页（禁止全局深分页）。设计核…

6
# MySQL

MySQL 分库分表中间件有哪些？ShardingSphere 和 MyCat 怎么选？

ShardingSphere（Apache，现 ShardingSphere 5.x）：① JDBC 模式（Sharding-JDBC）：应用内数据源代理，无中间件部署、性能好、语言绑定 Java；② Proxy 模式（Sharding-Proxy）：独立代理（兼容 MySQL 协议），任意语言客户端接入、集中治理；支持分片、读写分离、分布式事务（XA/Seata）、数据加密、影子库。MyCat：独立代理中间件（类似 Proxy），配置…

7
# MySQL

MySQL 分库分表后全局唯一 ID 怎么生成？

方案：① 数据库自增步长：多库自增步长不同（1,3,5... 与 2,4,6...）——简单但扩容要改步长；② 号段模式（美团 Leaf-segment）：DB 批量取号段缓存内存发号——性能好、有序、依赖 DB；③ 雪花算法（Snowflake）：时间戳+机器 ID+序列号（64 位）——趋势递增、高性能、无 DB 依赖，需处理时钟回拨；④ Redis INCR：简单但依赖 Redis、有持久化丢号风险；⑤ UUID：全局唯一但无序、…

8
# MySQL

MySQL 分片键怎么选？分片路由策略有哪些？

分片键选择原则：① 业务访问最频繁的条件（WHERE 高频列），保证大部分查询单分片路由（如订单按 user_id、按 order_id）；② 数据分布均匀（避免热点分片，如按用户 ID 哈希/取模）；③ 不可变或低频变更（改分片键=数据搬迁）。路由策略：① 范围分片：按 ID/时间区间（天然支持范围查询，但可能热点不均）；② 哈希取模：hash(key) % N（均匀，但扩缩容需迁移数据，可用一致性哈希/虚拟槽缓解）；③ 一致性哈希：…

9
# MySQL

MySQL 水平分表和垂直分表有什么区别？

垂直分表：把一张宽表按字段拆成多张表——常用字段一张、大字段/低频字段一张（如商品表拆基础信息表 + 详情表），减少单行长度、提升行密度与缓存效率；跨表查询需 JOIN（或冗余）。水平分表：按分片键把行拆到多张结构相同的表（user_0/user_1...，或按库），解决单表数据量与写入瓶颈；同一业务数据被拆分，跨分片查询/聚合复杂。垂直分库：按业务模块拆库（订单库/用户库），解耦、独立扩展。实践：先垂直（业务/字段）再水平（数据量）。

10
# MySQL

MySQL 为什么要分库分表？什么情况下才需要？

单库瓶颈：① 容量：数据量巨大（单表千万~亿级、库几十 TB）存储/备份慢；② 并发：单库连接数/IO/CPU 打满，读写争抢；③ 单表过大：索引深度、扫描成本高。分库分表时机（先做其他优化再考虑）：① 单表数据量过大且无明显缓解手段（通常建议提前规划，如预估单表 > 2000 万-5000 万行）；② 写并发高、单库写成为瓶颈；③ 归档无法解决容量增长。方案：垂直拆分（库按业务模块拆、表按字段拆）→ 水平拆分（按分片键把数据分布到多表…