技术文章 TiDB 社区博客 - 实践案例 2026/11/05
文章以一张销售明细表贯穿，系统讲解 TiDB 窗口函数的语法和三类常见用法：用 ROW_NUMBER、RANK、DENSE_RANK 做排名，用 SUM、AVG 配合 OVER 做累计、占比和移动平均，用 LAG、LEAD 做环比与上下行对比，并补充 ROWS BETWEEN、NTILE 等进阶窗框和分桶技巧。文中给出可复制的建表数据、完整 SQL、运行结果解释，以及 TopN、城市内占比、环比和综合销售看板案例。作者还集中说明 WHERE 不能直接过滤窗口函数、累计求和漏写 ORDER BY、LAG 首行为 NULL 等六个易错点，并展示 pandas 通过 pymysql 读取 TiDB 查询结果的方式。文章基于 TiDB 8.0.11-TiDB-v8.5.3 和 MySQL 8 兼容语法，侧重入门与常用分析场景，未深入执行计划、性能调优或 TiDB 特有优化。
推荐收录。文章不是只罗列语法，而是用同一销售数据集给出可运行 SQL、结果解释和 TopN、累计、环比、占比综合案例，并集中列出 WHERE 执行时序、累计漏 ORDER BY、LAG 首行 NULL 等易错点，适合 SQL 初学者、数据分析师和 TiDB/MySQL 使用者查阅。其模板和避坑清单可迁移到日常分析 SQL，但性能调优与 TiDB 特有优化需另行补充。
工程实践 TiDB 社区博客 - 实践案例 2026/11/05
文章复盘一条订单查询从 MySQL 迁到 TiDB 后变慢的排查过程：查询按 status 与 created_at 过滤并按时间倒序取 20 条，作者起初加联合索引却无效。改用 EXPLAIN ANALYZE 后，他发现优化器走 TableFullScan、扫描约 120 万行；根因是统计信息过期，使 CBO 误判索引回表代价。执行 ANALYZE TABLE 后计划改用索引，耗时从约 2 秒降到 80 毫秒；文中还提醒大表可采样分析，并介绍执行计划绑定作为兜底。最后作者对比 MySQL 的局部修补与 TiDB 先看全局计划的思路。该案例具体但属单点入门经验，未展开完整基准和 binding 语法细节。
推荐收录：文章用可复现的排查链条说明 TiDB 调优不能只靠加索引——从 EXPLAIN ANALYZE 定位 TableFullScan，到检查统计信息并用 ANALYZE TABLE 验证，再到 plan binding 兜底，路径清晰。适合使用 TiDB 或分布式数据库的后端、DBA 读者借鉴；但只是单案例入门经验，正式 binding 命令和基准数据缺失，不能替代系统化优化手册。
技术文章 PlanetScale Blog 2026/10/27
文章追问 Postgres 何时成为默认选择，按时间线串联其可扩展设计与 BSD 许可证、Postgres95 转向 SQL 和社区治理、Oracle 收购 MySQL 后的信任变化、Heroku 默认托管、JSONB 回应文档数据库，以及 2023 年调查超越 MySQL。作者结合 DB-Engines 与 LLM 选择数据，认为没有单一转折点，而是刻意设计与偶然托管选择共同作用。文章也承认 Postgres 在水平分片和大规模性能上仍需追赶，MySQL/Vitess 仍有成熟负载。结尾含 PlanetScale 推广，结论需考虑 vendor 立场。
推荐收录：文章以 Stack Overflow、DB-Engines 和 LLM 数据库选择数据为直接依据，按节点解释 Postgres 的生态、许可证、托管便利与 NoSQL 竞争，适合数据库选型、平台工程和开源治理读者理解技术采纳路径。可迁移的是从社区治理、默认托管和扩展生态评估数据库长期走向；主要风险是作者来自 PlanetScale，文末含产品推广，需对结论保持 vendor 视角。
工程实践 TiDB 社区博客 - 实践案例 2026/10/16
文章复盘网易外贸通从 RDS 迁移到 TiDB 的真实架构升级实践。面对 RDS 单实例 2TB 磁盘上限、大表 DDL 长达两三天、存储成本偏高及缺乏实时分析等问题，团队基于高度兼容 MySQL、存算分离与 HTAP 能力选择 TiDB。迁移后同样的数据单副本从 1134.25G 压缩到 345G，部分文本表压缩比达 1/8，DDL 降至秒级且不阻塞业务读写，数十亿行大表可做 T+0 联合查询，并可用 SPM 直接绑定执行计划而无需发版。文中还总结了优先选自增主键聚簇表、用完整库导入验证真实压缩比、修改 BR 源码适配 100MB 块限制的自研对象存储、借 TiCDC 搭建可回滚反向链路等经验，并初步探索仅只读权限的 AI 运维。整体偏厂商实践分享，收益数据为单方披露，结尾带企业版推介。
推荐收录。文章给出可核验的具体证据：压缩比从 1134G 降到 345G、DDL 由两三天变为秒级、以 TiCDC 保证迁移可回滚，并点出非聚簇表引发空间放大与性能下降、BR 元数据触发 100MB 块限制等真实踩坑。适合正在做 MySQL/RDS 向分布式数据库迁移的 DBA 与架构师参考，其选型方法、压缩验证流程和回滚链路设计可迁移；但收益数据为单方口径且结尾含企业版推介，需结合自身场景验证。
工程实践 Cloudflare Blog 2026/10/14
文章介绍 Cloudflare Hyperdrive 对 MySQL 的支持正式 GA，并以一个出现率约 0.001% 的罕见缓存 bug 为主线，完整复盘从现象定位到根因修复的过程。Hyperdrive 是分布式数据库连接池，采用 Client 与 Endpoint 双节点架构，两者共用所在数据中心的 CDN 缓存以加速查询。作者先排除网络与用户逻辑问题，发现 bug 只出现在开启缓存的实例上，进而深入 MySQL 客户端/服务端协议的能力协商机制。根因在于 Client 节点会把响应翻译成 Worker 客户端（如 mysql2 不支持 CLIENT_DEPRECATE_EOF）期望的能力格式再写入缓存，而 Endpoint 始终以 Hyperdrive 自身能力格式读写，二者共享缓存时读到格式错配的字节，导致空结果或挂起。修复方式是无论哪个节点都统一缓存以 Hyperdrive 能力编码的规范化结果，Client 连接成功率恢复到 99.99%。文中还记录了 utf8mb3/utf8mb4 与 COM_RESET_CONNECTION 引发的编码类 bug，可作为连接池与协议代理实现的边界参考。
推荐收录，因为它是一次真实且边界明确的线上疑难问题复盘：从 0.001% 的空结果现象出发，通过遥测、协议文档与代码分析逐步收敛到能力协商与共享缓存格式错配这一根因。对做数据库连接池、协议代理或分布式缓存的工程师来说，其排查顺序、假设修正和规范化缓存的设计取舍都可迁移到同类系统。
工程实践 PlanetScale Blog 2026/09/28
文章以 PlanetScale 的 Neki 分片方案为背景，讨论多租户场景下的热分片问题：按 tenant_id 均匀分布租户在业务增长后会失效，出现超大租户压垮单个分片、跨租户查询增多等情况，即租户均匀不等于数据均匀。作者引用 Slack 使用 Vitess 的真实案例，说明 messages 表从按 workspace 分片改为按 channel 分片后，把常用的单分片查询保持在一起、把跨分片查询限制在批量或管理路径，从而降低热点并获得 CPU 与存储余量。文中给出三级处置路径：纵向扩容、按 key range 隔离大租户，以及最终按访问模式和查询形状重新分片部分表，并说明 Neki 用声明式 data topology 与在线 Reshard 在不停机的情况下迁移数据。边界在于内容带有产品宣传色彩，缺少性能基准和失败案例，Postgres 与 MySQL 的表述也略有出入，读者需结合自身系统验证。
推荐收录：文章把热分片的成因与三类处置路径（扩容、按 key range 隔离大租户、按访问模式重分片）讲得具体，并给出 Slack/Vitess 的迁移决策依据与 key range 配置示例，可迁移到多租户 SaaS 的分片键复审。适合负责分库分表、租户隔离与在线扩容的工程师和架构师；但结论围绕厂商产品，缺少量化基准，引用前需自行压测验证。
工具笔记 ClickHouse Engineering 2026/09/11
文章介绍如何借助 clickhouse-local 与 ClickHouse 的 mysql 表函数，把 S3 上的 StackOverflow 投票 Parquet 数据直接写入并在 MySQL 中查询，因为 MySQL 本身没有原生导入 Parquet 的方式。作者用 Docker 启动 MySQL 8.4，下载 ClickHouse 二进制，并通过 ch-config.yaml 定义命名集合 mysql_demo 保存连接凭据。核心步骤包括用 DESCRIBE url() 探查 Parquet schema、在 MySQL 建表，再执行 INSERT INTO FUNCTION mysql(...) SELECT ... FROM url() 导入约 230 万行数据。文章重点区分两种查询方式：在 FROM 中写 ClickHouse 子查询时，ClickHouse 会解析并改写成 MySQL 合法 SQL；而通过 query() 传入字符串则原样下发，因此含 tuple 等 ClickHouse 特有函数会直接报错。作者也说明示例为本地演示环境，凭据以明文参数传入，生产系统应改用环境变量。
推荐收录，因为它给出可复现的完整方法，解决 MySQL 无法原生导入 Parquet 的真实数据搬运问题，并明确划出 mysql 表函数的两条边界：ClickHouse 子查询会被改写为 MySQL SQL，而 query() 字符串原样下发，这一区别容易踩坑。适合做 ETL、跨库迁移或用 clickhouse-local 做临时数据处理的工程师参考，命名集合与批量 INSERT 写法可直接迁移；不足是偏操作步骤，性能与生产安全约束讨论有限。
工程实践 PlanetScale Blog 2026/08/31
文章以GitHub面试题为引，解析了一个真实数据库故障链路：一个应用异常导致事务未提交，连接持有读锁；随后一个需要排他锁的schema change被阻塞，而后续所有对同一表的查询都排队等待，最终整个应用无法执行查询。作者用Postgres和MySQL的例子逐步复现了该过程，并指出根因之一是Postgres默认关闭的idle_in_transaction_session_timeout。文章随后介绍了PlanetScale提供的连接管理工具，包括Dashboard和CLI，可以查看阻塞连接、取消查询、终止事务或断开连接，并强调了保留管理连接以应对连接耗尽场景的设计。最后也涉及了该场景下如何避免锁等待以及Vitess在线DDL的优势，但文章带有明显的产品推广倾向。
文章清晰还原了未提交事务阻塞迁移并拖垮整个数据库的典型故障链路，提供了可复现的实验步骤和根因解释，对数据库运维、DBA和应用开发者都有直接参考价值。虽然结尾有PlanetScale产品推广，但核心的技术分析和锁排队原理可迁移到任何关系型数据库场景，值得收录。
工程实践 TiDB 社区博客 - 实践案例 2026/08/27
作者结合TiDB免费认证学习经历，对TiDB与OceanBase做了MySQL语法兼容性对比测试。测试围绕外键关联表、RANGE/LIST/HASH及复合分区表、在线索引DDL、前缀索引和存储过程等对象的DDL/DML展开，并检查执行计划与错误提示。结果显示两者对MySQL基本语法均兼容，都支持外键约束、普通分区和在线加索引；差异在于TiDB不支持复合分区与存储过程，OB支持；索引选择路径与报错信息也有不同。文章给出完整测试SQL、版本信息和结果截图，但未涉及性能、事务隔离、复杂查询等场景，对比深度停留在功能支持层面，且针对特定版本，结论时效性有限。
文章以可复现的SQL脚本和截图直接对比TiDB与OceanBase在MySQL兼容性上的功能差异，覆盖外键、分区、索引和存储过程等迁移常见场景，对分布式数据库选型和MySQL业务迁移评估有直接参考价值。适合DBA、架构师和迁移项目成员；测试方法可迁移，但结论基于特定版本，使用时需结合最新版本文档复核。
工程实践 TiDB 社区博客 - 实践案例 2026/08/13
文章复盘学科网阅卷系统从 MySQL 迁移到 TiDB 的实践，背景是业务具有峰谷特征、单机 MySQL 主备集群出现容量与性能瓶颈，同时研发资源有限无法改造代码。作者详细说明选型 TiDB 的关键理由：高度兼容 MySQL 实现零代码迁移、在线 DDL 不阻塞业务、弹性扩缩容适配流量波动、Raft 多副本保证数据强一致。迁移采用分批策略，优先将大表和主从延迟严重的表迁入，收益包括缓解并发压力、消除切换数据不一致风险、节省磁盘空间并避免分库分表改造。文中还总结了扩容规划、小表热点处理、低峰版本升级和索引优化等运维经验。该方案尤其适合教育行业等需要兼容 MySQL 且短时高并发的场景，但需注意跨 AZ 缩容的数据分布和热点小表的处理。
推荐收录，因为文章提供了真实业务约束下的数据库选型、迁移和运维全过程，包含零代码改造、在线 DDL、强一致、扩容规划、小表热点等具体细节，不是泛泛的技术宣传。适合数据库架构师、SRE 以及教育行业技术负责人参考，其“先兼容迁移、争取时间”的平滑演进思路可迁移到其他受限于 MySQL 单机瓶颈且短期无法大改代码的团队。
工程实践 PlanetScale Blog 2026/08/07
文章复盘了一次 MySQL 生产事故：一个长事务导致 InnoDB 版本历史膨胀，使读查询成本随并发量平方级增长，最终拖垮数据库。作者运用 Gunther 通用可伸缩性定律解析了争用系数 α 与一致性开销系数 β，阐明为何超过临界并发数后吞吐量反而下降。解决方案是将 Vitess 事务池从一万降低到约一千并引入排队，模拟原有线程池的反压行为，从而避免大量并发请求涌入存储引擎。配置变更后，系统在类似流量尖峰下吞吐稳定、无报错，MySQL 内部并发数控制在两百以内。文章强调此策略适用于悲观锁、热点行等高争用场景，且思路可迁移至 Postgres 等系统。
推荐收录，因为文章通过真实事故展示了并发与吞吐的逆向关系，并用通用可伸缩性定律提供量化分析。对负责高并发数据库、稳定性工程及反压机制设计的读者具有直接参考价值，可迁移到类似数据库和分布式系统中。文中提供的实验数据和配置对比使其结论可信，且明确给出了适用边界。
技术文章 PlanetScale Blog 2024/01/25
这篇文章系统介绍了如何在 MySQL 中表示和处理地理空间数据，先区分了实体、空间两类地理对象，再说明 POINT、LINESTRING、POLYGON 及其多几何类型在表中的存储方式。作者进一步解释了 WKT、WKB 和 MySQL 内部格式的区别，以及 SRID 如何决定坐标系和计算语义。文中给出了创建带 SRID 4326 的空间列、添加 SPATIAL KEY 的建表示例，并演示了距离、面积、包含、相交、缓冲、并集和差集等常用空间函数。最后比较了 MySQL 8 与 5.7 在 SRS 感知和空间索引上的改进，指出旧版本常在平面坐标和最小外接矩形上计算，精度和可用性都受限。整体适合作为入门到实操的参考，但示例主要覆盖基础用法，复杂 GIS 场景仍需结合具体投影与数据分布验证。
文章直接给出了 MySQL 空间数据类型、SRID、空间索引和常用函数的示例，证据充分，适合需要在数据库中存取地理位置、做邻近查询或范围分析的开发者。它的可迁移价值在于把“如何建表、如何查询、MySQL 8 为什么更准确”讲清楚；主要限制是停留在基础教程层面，复杂投影和大规模 GIS 负载还需进一步验证。