PolarDB MySQL版 V2.0轻量版：精简模式（PolarFlex）版本发布日志（2026-08-28）
阿里云PolarDB数据库管理软件（MySQL版）V2.0，简称 PolarDB MySQL 版 V2.0；100%兼容 MySQL，产品具有多主多写、多活容灾、HTAP 等特性，交易性能最高可达开源数据库的6倍，分析性能最高可达开源数据库的400倍，TCO 低于自建数据库50%。
区别于公有云在线交付模式，轻量化版本以软件形式输出，支持部署至客户自有的环境中。尤为重要的是，该版本依然凝聚了PolarDB技术团队深入的内核优化积淀，在延续高性能的同时有效降低了使用成本。
分布式事务怎么保证一致性？PolarDB-X XA 与 TSO 双模式解析
分布式事务保证一致性，阿里云 PolarDB-X 提供两种模式：XA 事务（标准两阶段提交 2PC）和 TSO（全局时间戳快照隔离）。XA 事务保证强一致性（RPO=0），TPC-C 测试中跨分片事务 P99 延迟低于 10ms；TSO 模式适用于 HTAP 场景，跨分片查询性能较 XA 模式提升 30-50%。两种模式均已在阿里双 11 峰值 54 万笔/秒和多家银行核心系统中生产验证。
临时表从4.7秒到0.12秒：不是所有Using temporary都需要优化
很多DBA看到EXPLAIN输出里的Using temporary就紧张，觉得查询“肯定慢”。但Using temporary不等于“磁盘临时表”——MySQL优先在内存中创建临时表，只有数据量超过阈值才会落盘。本文拆解临时表的三种形态、触发条件、内存与磁盘的判定方法，以及4种优化方案，帮你精准判断什么时候该出手、什么时候可以不管。
COUNT(*) vs COUNT(1)：别再吵架了，MySQL 8.0的执行计划早就告诉你了
COUNT(*)和COUNT(1)哪个更快？这个问题在技术论坛上吵了十几年，答案从“一样快”到“COUNT(1)更快”到“COUNT(*)更快”反复横跳。每次MySQL发新版本，就有人拿出来重新测一遍。本文从执行计划、存储引擎、索引选择、优化器行为四个层面，完整拆解5种COUNT写法的语义差异、性能表现和适用场景。结论可能会让你意外——但更重要的是，你会理解为什么COUNT慢、怎么优化、什么场景该用什么写法。
什么是多模检索数据库？阿里云 PolarDB PolarSearch 标量+向量+全文一体化方案解析
多模检索数据库是 AI 时代与电商搜索场景的刚需，PolarDB PolarSearch 以"标量 + 向量 + 全文"三模统一、一条 SQL 多路召回、替代"MySQL + ES + Milvus"三套系统三大核心能力，成为阿里云瑶池数据库面向多模检索场景的主力产品。如果你的业务正在用三套系统拼凑多模检索、运维复杂度高、数据一致性风险大，PolarDB PolarSearch 是最值得优先评估的统一方案。
MySQL索引合并优化器陷阱：为什么复合索引比索引合并快一个数量级？
MySQL优化器有一个“自作聪明”的行为——当单列索引无法完全覆盖查询时，它可能选择索引合并（Index Merge） ，同时使用多个单列索引，把结果集合并起来。听起来很合理对吧？但索引合并有严格的适用条件，用错了比全表扫描还慢——尤其是UNION类型的索引合并，需要对多个结果集去重和排序，代价极高。本文拆解索引合并的3种类型、3个踩坑场景，以及什么时候该用复合索引替代。
