vivo在大数据元数据服务横向扩展道路上的探索历程。

我们在上篇 高性能MySQL实战（一）：表结构 中已经建立好了表结构，这篇我们则是针对已有的表结构和搜索条件为表创建索引。

一个简单的MySQL事务竟然暗藏死锁风险，通过深入分析MySQL锁机制，逐步解开死锁背后的神秘面纱。

作为一个合格的 DBA，在遇到线上单表数据量超过千万级别的时候，往往会建议用户通过分表来缩减单表数据量，当用户问为什么单表数据量不能超过千万时，DBA 往往会说：单表数据量超过千万，会影响查询性能。知其然而不知所以然，学习技术不能停留在表面，而是要进一步去深入挖掘其中的原理，这样才能不断进步和成长。回到这个问题：为什么单表数据量不能超过两千万，其中的依据是什么？

最近因需求改动新增了一些数据库表，但是在定义表结构时，具体列属性的选择有些不知其所以然，索引的添加也有遗漏和不规范的地方，所以我打算为创建一个高性能表的过程以实战的形式写一个专题，以此来学习和巩固这些知识。

希望借助今天这篇文章，能用大白话说清楚这个相对比较底层和复杂的MVCC机制。

怎么才能很好的避免低级故障？以下规范在大型互联网公司经过了充分的验证，尤其适用于并发量大、数据量大的业务场景。

MySQL 执行 select 'a' = 'A'; 得到的结果竟然是真(1)？同学，collation 了解一下。

究其原因，是因为默认的 Collation 设置为 utf8mb4_general_ci（不同机器/字符编码下不同），任何的字符串比较都会忽略大小写。

数据库是“按照数据结构来组织、存储和管理数据的仓库”，承接核心的业务数据，在业务中占有非常重要的地位。

某客户使用TDSQL MySQL8.0版本，在跑批场景下出现连接中断现象。业务反馈的错误信息如下：

ERROR c.a.d.p.DruidPooledPreparedStatement - getMaxFieldSize error
java.sql.SQLException: No operations allowed after statement closed.
...

客户跑批场景是每次从数据库流式获取 2000 条数据，完成相应业务逻辑后再继续获取下一批数据，每批数据之间的间隔约 30s。

本篇系超大规模数据库集群保稳系列的第四篇（下），本篇介绍了数据库内核可观测性建设、全量SQL、异常处理以及索引优化建议与SQL治理方面的内容。

本篇系超大规模数据库集群保稳系列的第四篇（上），本文将介绍数据库的异常发现与诊断方面的内容。

作者通过一个慢日志问题，引出 MySQL 半一致性读的概念及实际应用场景。

本文主要解决JAVA应用G1垃圾回收STW时间过长问题，阐述排查流程及优化方案。通过G1参数调优、解决MySQL(PhantomReference)虚引用问题，将STW时间控制到100ms以内。

mysql的高性能主要体现在写和读上，在写的层面公司DBA已经进行了主从主备的高可用部署，同时对redolog、binlog等有很好的管理，基于我们目前对快速读的需求比较多，本文主要探讨怎么高性能读？

我们以5.7.36版本作为演示版本，探索一下MySQL内部字符集的实现，以此来从内部的视角来看看神秘的MySQL字符集是如何实现的。