MySQL是一个关系型数据库管理系统，由瑞典 MySQL AB 公司开发，属于 Oracle 旗下产品。MySQL是最流行的关系型数据库管理系统之一，在 WEB 应用方面，MySQL是最好的RDBMS (Relational Database Management System，关系数据库管理系统)应用软件之一。
mysql的innodb和myisam索引区别
InnoDB和MyISAM是MySQL中的两种存储引擎，它们在事务处理、锁定级别、索引结构以及全文索引等方面存在区别：
- 事务处理：InnoDB支持事务处理，能够进行提交和回滚操作，而MyISAM不支持事务处理。
- 锁定级别：InnoDB支持行级锁，提供更高的并发性能；MyISAM仅支持表级锁，可能在执行写操作时导致整张表被锁定。
- 索引结构：InnoDB使用聚簇索引，数据文件和主键索引绑定在一起，通过主键索引的查询效率较高；MyISAM使用非聚簇索引，数据文件与索引分开存储。
- 全文索引：MyISAM支持全文索引，对于全文搜索有较好的性能；InnoDB直到MySQL 5.6版本才开始支持全文索引。
- 外键约束：InnoDB支持外键约束，用于保证数据的完整性；MyISAM不支持外键。
- 计数操作 ：MyISAM保存了表的行数，对
SELECT COUNT(*)操作较快；InnoDB没有保存这个信息，需要全表扫描来计算行数。 - 恢复能力：系统崩溃后，MyISAM表的恢复相对困难；InnoDB因其事务日志而具有更好的恢复能力。
- 内存使用：InnoDB采用缓冲池来缓存数据和索引，减少磁盘I/O；MyISAM对内存的使用不如InnoDB高效。
- 自动提交 ：对于InnoDB，每条SQL语句默认封装成事务并自动提交，可以通过显式地使用
BEGIN和COMMIT来控制事务；而MyISAM不涉及事务的自动提交问题。
综上所述，InnoDB适合处理并发高及需要事务支持的场景，而MyISAM适合读取密集型的应用且不需要事务支持的情况。在选择存储引擎时，应考虑应用的具体需求，比如是否需要事务支持、并发访问量、是否需要全文索引等因素。
InnoDB引擎的4大特性
InnoDB引擎作为MySQL的默认存储引擎，拥有以下四大特性：
- 支持事务处理：InnoDB引擎支持完整的ACID事务，允许用户进行可靠的提交和回滚操作。这是通过其MVCC（多版本并发控制）机制以及强大的恢复能力实现的，确保了在并发环境下数据一致性和完整性。
- 外键约束：InnoDB支持外键约束，这有助于保持数据库中数据的参照完整性。通过外键可以创建一个表与另一个表之间的链接，确保数据的相关性和准确性。
- MVCC（多版本并发控制）：InnoDB通过MVCC实现了非锁定读，这意味着在读取数据时不会对其进行锁定，从而允许其他事务同时对数据进行写入。这种机制提高了数据库在高并发情况下的性能。
- 行级锁定：InnoDB提供了行级锁定功能，相比于MyISAM的表级锁，行级锁可以更精细地控制并发访问，减少锁冲突，提高并发性能，特别适合于在线事务处理（OLTP）类型的应用。
除了上述特性，InnoDB还具有一个高度优化的缓冲池来减少磁盘I/O操作，以及聚集索引来提高主键查询的效率。这些技术特性共同作用，使得InnoDB成为处理大数据量和需要高并发访问场景下的理想选择。
插入缓存的合并频率是多少？
在MySQL中，InnoDB存储引擎有一个名为"插入缓冲"（Insert Buffer）的组件，它用于优化辅助索引（非聚簇索引）上的插入操作。当多个插入操作涉及到同一个辅助索引页时，这些变更会被合并到所谓的"插入缓冲"中，而不是直接更新索引页。
在MySQL 5.6版本之前，InnoDB有一个被称为"自适应哈希索引"（Adaptive Hash Index）的功能，它会根据表的大小和负载自动开启或关闭。插入缓冲的默认合并频率与自适应哈希索引有关，通常是每秒一次。但是，这个频率是动态调整的，并且受到很多因素的影响，如系统负载、I/O性能等。
从MySQL 5.6开始，InnoDB不再使用自适应哈希索引，而是引入了一个新的称为"更改缓冲"（Change Buffer）的机制来处理对辅助索引的随机插入操作。更改缓冲的合并策略也有所不同，并且会考虑更多的因素，比如数据页是否已经被加载到内存中。
在现代版本的MySQL中，插入缓冲被更改缓冲所替代，而更改缓冲的具体合并时机更加智能，不依赖于固定的频率，而是根据服务器的工作负载和数据访问模式来动态调整。因此，没有一个固定的"合并频率"可以描述当前InnoDB引擎的行为。相反，InnoDB引擎会根据需要自动合并更改缓冲中的操作到辅助索引页中。
要了解特定MySQL版本和配置下插入缓存（或更改缓冲）的合并行为，最好查阅该版本的官方文档或相关资源。
二次写空间组成？
InnoDB引擎的二次写（Doublewrite）由两部分组成：
- 内存中的Doublewrite Buffer：这是位于InnoDB存储引擎内存中的一个缓冲区，其大小通常配置为2MB。这个缓冲区用于在写入数据页到磁盘之前，先将数据的一份副本写入这个buffer。这样做的目的是为了在发生部分写失败或掉电等异常情况时，能够从这个buffer中恢复数据，保证数据的完整性。
- 物理磁盘上的共享表空间：在InnoDB存储引擎的共享表空间（ibdata文件）中，有一块专门的区域用于二次写，它由连续的128个页面组成，分为两个区（extent），每个区的大小也是2MB。当数据被写入内存中的doublewrite buffer后，接下来会写入到这个共享表空间的doublewrite区域。如果写入成功，数据才会被写入到最终的位置。
二次写机制是InnoDB确保在发生故障时数据可靠性和一致性的一种技术。通过这种双重保障措施，即使在系统崩溃或其他异常情况下，InnoDB也能通过这个"双保险"机制来减少数据丢失和损坏的风险。
自适应hash索引有什么坏处
自适应哈希索引（Adaptive Hash Index，AHI）是InnoDB存储引擎特有的一种优化技术，虽然它能在某些情况下提供性能上的提升，但也存在一些潜在的缺点和限制：
- 占用Buffer Pool内存：AHI会在InnoDB的buffer pool中创建额外的哈希索引结构。这会增加内存的使用量，如果内存有限，可能会导致原有数据被置换出缓存，从而影响其他操作的性能。
- 只适用于等值查询：AHI主要针对的是等值查询，即精确匹配某个值的查询。对于范围查找、模糊查询或者需要排序（ORDER BY）的操作，AHI无法提供优化支持。
- 可能降低写操作性能：尽管AHI可以加速读操作，但在某些情况下可能会对写操作产生负面影响。因为每次数据变更都可能需要更新哈希索引，这会增加写操作的复杂性和开销。
- 可能导致数据不一致：在系统崩溃或其他异常情况下，由于AHI是在内存中构建的，因此可能存在数据丢失或损坏的风险。虽然InnoDB有恢复机制，但在极端情况下仍可能面临数据一致性问题。
- 自动创建可能导致不可预测性：AHI会根据服务器的工作负载自动创建和删除。这种自动行为可能导致数据库管理员难以预测和控制索引的使用情况，从而影响系统的稳定性和管理的便捷性。
- 不支持热数据的二级索引优化：虽然AHI可以基于二级索引的频繁访问来创建哈希索引以加速搜索，但这仅限于等值比较，不支持其他类型的优化。
总的来说，AHI在特定的应用场景下可以提高查询效率，尤其是在处理大量等值查询时。但是，它也有一些局限性和潜在的副作用，特别是在写密集型的工作负载或者需要复杂查询支持的应用中，AHI可能不是最佳选择。因此，在使用AHI时，需要根据具体的应用场景和工作负载来权衡其利弊。