Mysql相关

• 自增初始值和自增步长设置不为 1
• 唯一键冲突
• 事务回滚
• 批量插入（如 insert…select 语句）

• MySQL 主要通过原子性、隔离性、持久性来保证一致性。
• ACID 四大特性之中，C（一致性）是目的，A（原子性）、I（隔离性）、D（持久性）是手段，是为了保证一致性。

• MySQL 中多个日志的原因：每个日志都有其特定的用途，用于实现不同的功能，如记录事务操作、保证数据的一致性和可靠性等。

• 间隙锁用于锁定间隙，防止其他事务在间隙中插入数据；
• 临键锁是间隙锁和行锁的组合，用于锁定记录及其相邻的间隙；
• 意向锁用于表示事务对表中数据的意向操作。
• MySQL 中的不可重复读和幻读：
  • 不可重复读是指在同一事务中，多次读取同一数据时，结果不一致；
  • 幻读是指在同一事务中，多次执行相同的查询，结果集不一致。

• 间隙锁引发的死锁问题：当多个事务同时持有间隙锁并互相等待对方释放锁时，可能会导致死锁。

• MySQL 解决 RR 级别下的幻读：通过使用间隙锁和临键锁来解决幻读问题。

• 常见的分库分表框架有 Sharding-JDBC、MyCat 等，
• 方案包括垂直分库、水平分库和水平分表等。

• MVCC 是一种并发控制技术，通过保存数据的多个版本来实现并发操作。
• 当前读是读取最新版本的数据，快照读是读取指定版本的数据。

• 可能是由于查询的数据量过大，导致数据库需要进行全表扫描或大量的磁盘 I/O 操作。
• MySQL 请求大数据慢的原因：可能是由于数据量过大、网络延迟、数据库配置不合理等原因导致的。
• 数据的查找过程：通常包括索引查找、数据读取和结果返回等步骤。

• 连接池的实现原理：连接池通过维护一定数量的数据库连接，避免频繁地创建和释放连接，提高数据库操作的性能。

• MySQL 记录丢失的情况：在数据库崩溃、硬件故障或人为错误等情况下，可能会导致 MySQL 记录丢失。
• MySQL 同步刷盘的方式：可以通过配置 innodb_flush_log_at_trx_commit 参数来控制同步刷盘的方式

• 索引是一种用于提高数据库查询效率的数据结构。在 MySQL 中，常见的索引类型包括：
• 主键索引（PRIMARY KEY）：唯一标识表中的每一行数据，一个表只能有一个主键索引。
• 唯一索引（UNIQUE）：确保索引列的值是唯一的。
• 普通索引（INDEX）：可以加快数据的查询速度。
• 组合索引（也叫联合索引）：由多个列组成的索引。
• MySQL 索引的数据结构主要有 B 树和 B+树。

B 树和 B+树的区别主要有以下几点：

1. B+树的非叶子节点不存储数据，只存储索引信息，而 B 树的非叶子节点和叶子节点都会存储数据。
2. B+树的叶子节点之间通过链表相连，便于范围查询，而 B 树则没有这样的链表结构。
3. B+树的所有数据都存储在叶子节点，而 B 树的数据可以存储在非叶子节点和叶子节点。

• 没有用上索引或索引失效。
• 数据库在刷新脏页，例如 redo log 写满了需要同步到磁盘。
• 执行的时候遇到锁，如表锁、行锁。

排查方法如下：

• 使用 EXPLAIN 命令
• EXPLAIN 指标有那些？
  • 检查索引：确保查询使用了正确的索引，并且索引没有失效。
  • 检查锁：如果查询遇到了锁，可能会导致执行时间变慢。可以通过检查锁的状态来确定是否存在锁竞争。
  • 检查数据库配置：检查数据库的配置参数，如缓存大小、连接数等，确保它们适合当前的工作负载。

主从延迟的解决办法有以下几种：

1. 优化主库的写入性能，比如减少大事务、避免长事务。
2. 增加从库数量，分担读压力，减轻单个从库的同步负担。
3. 调整从库的参数，例如增大 `slave_parallel_workers` 来提高并行复制的效率。
4. 检查网络状况，确保主从之间的网络稳定且带宽足够。

以下情况不适合做读写分离：

1. 对数据一致性要求非常高，无法容忍主从延迟带来的数据不一致。
2. 读操作的并发量不大，主库能够承担读写压力。
3. 业务逻辑复杂，难以清晰地区分读和写操作。

1. Mysql锁：
   • 乐观锁： 在数据库中使用乐观锁机制，通过版本号或时间戳来确保库存更新的原子性。
   • 悲观锁： 在关键的库存扣减操作中使用悲观锁，确保在操作期间库存数据不会被其他事务修改。
2. 预扣库存： 在用户下单时预扣库存，但暂时不减少实际库存，直到支付完成后再确认扣减。
3. 库存预留： 对于高需求商品，可以在用户下单后立即预留库存，设置一个合理的预留时间，如果用户在这段时间内未完成支付，则释放库存。
4. 队列机制： 使用消息队列来管理订单和库存扣减操作，确保操作的 顺序执行 。
5. 分布式锁： 使用Redis分布式锁来保证跨多个节点的库存扣减操作的一致性。
   • 查询库存 和 扣减库存这个操作不是原子性的。可能会引起多线程并发问题。
   • 所以用基于redission的分布式锁可以解决这个问题。
   • lua脚本实现原子操作。
6. 限流： 对于高并发场景，通过限流来控制同时处理的订单数量，减少超卖的风险。
7. 订单取消策略： 设定订单取消策略，对于超卖的订单，自动取消并给予用户适当的补偿。

1. 索引优化
   • 确保对经常用于查询条件的列建立索引。
   • 避免对大型表的非前缀列使用全文索引。
   • 定期重建索引以减少碎片化。
2. 查询优化
   • 优化SQL语句，避免使用SELECT *，只获取需要的列。
   • 使用EXPLAIN关键字分析查询语句的执行计划。
   • 避免在WHERE子句中使用函数，因为这会导致索引失效。
3. 数据类型优化
   • 选择合适的数据类型，避免过度使用大型数据类型，如VARCHAR(255)。
4. 表结构优化
   • 将大表拆分为多个小表，以减少单个查询的数据量。
5. 读写分离
   • 在高并发场景下，使用主从复制和读写分离来分散数据库负载。
6. 数据库监控
   • 使用监控工具来跟踪慢查询、性能瓶颈和资源使用情况。
7. 定期维护
   • 定期进行数据库维护，如优化表（OPTIMIZE TABLE）、清理碎片等。

1. 性能下降
   • 大量的数据处理会消耗更多的CPU和I/O资源，导致查询响应时间变长。
2. 锁竞争
   • 在高并发环境下，多个事务可能会争用同一资源，导致锁等待和死锁。
3. 内存溢出
   • 如果查询操作需要大量内存来缓存数据，可能会导致内存不足。
4. 网络瓶颈
   • 大量数据的传输可能会占用大量网络带宽，影响其他操作。
5. 数据库崩溃
   • 在极端情况下，资源耗尽可能导致数据库服务崩溃。
6. 慢查询
   • 大表上的复杂查询可能会执行很长时间，影响用户体验。
7. 数据不一致
   • 如果查询操作涉及到大量的数据更新，可能会导致数据不一致。
8. 备份和恢复时间延长
   • 大表的备份和恢复操作可能会非常耗时。