mysql

MariaDB server是 MySQL server的一个社区开发的分支。MariaDB由最初的 MySQL 团队的核心成员开始，积极地与外部开发人员合作，交付业界最有功能、最稳定、最合法的 open SQL server。

将数据按照一定的规则分布到多个数据库（或表）中，进一步分担单个数据库的负载。通过将这两种方法组合使用，可以有效地分散数据库的读写负载，同时实现水平扩展。

在支持事务的存储引擎（如InnoDB）中，事务机制和锁定协议有助于维护索引的唯一性。当一个事务正在修改索引列时，其他事务对相同键值的修改会被适当地阻塞，直到第一个事务提交或回滚，确保数据的一致性和唯一性。

如果没有使用索引下推技术，MySQL 会通过 zipcode='95054'​从存储引擎中查询对应的数据，然后将结果返回到 MySQL 服务端，接着 MySQL 服务端再基于lastname LIKE '%etrunia%' 和 address LIKE '%Main Street%'来判断数据是否符合条件。

索引是提高 MySQL 查询性能的重要工具，但在使用索引时需要遵循一定的规则和最佳实践，以避免常见的索引失效问题。通过合理设计和维护索引，可以显著提升数据库的性能和响应速度。希望本文对你在 MySQL 索引的使用和优化方面有所帮助。

本文主要通过图示介绍了用主键进行分片查询的过程，介绍了主键分页查询存在SQL性能问题，如何去创建高效的索引去优化主键分页查询的SQL性能问题。对于数据分布不均如何发现，提供了一些SQL查询案例来进行参考，对MySQL Index Condition Pushdown优化算法做了一些简单介绍。

MySQL 中的日志非常重要，包括实例内的事务以及实例间的主从复制均基于日志实现。

MySQL 普遍采用 B+Tree 实现，索引本身很大，不可能全部存储内存，因此需要以索引文件的形式存储磁盘。

究竟是哪一行呢？本地可以调试的话很简单，Debug跟踪一下，但是预发布环境不能Debug呀！当然其实有些公司网是通的，可以做远程Debug，更多的是一个规范的问题。

使用Explan执行计划存在无法提前预知索引选择的局限性。然而，只要熟悉MySQL底层代价模型的计算公式，我们就能预知索引的走向。

在MySQL的InnoDB引擎中，支持多种锁级别，其中包括行级锁和表级锁，而共享锁，又被称为读锁，是由读取操作所创建的一种锁。

往期在文章《介绍Innodb的锁机制》中提到过关于记录锁，但是没有详细展开描述，本片文章简单聊一聊。

在可重复读隔离级别下，事务在开始时创建一个快照，事务内看到的数据都是基于这个快照的，因此它解决了“脏读”和“不可重复读”的问题。然而，这个级别仍然面临“幻读”的问题。

在没有主键的MySQL表中查找重复数据可能会有点复杂，但通过使用下述方法中的任何一种，你都应该能够识别并处理这些重复项。

本文介绍了先写MySQL后写Redis、使用事务或分布式锁、异步更新与消息队列以及延迟双删等策略来解决双写一致性问题，并提供了相应的实现步骤和代码示例。