MySQL索引优化有无一些心得，优化方法？

常见优化索引的方法：

前缀索引优化

ALTER TABLE users ADD INDEX idx_email(email(6));

这样，索引中只存储每个 email 字段的前 6 个字符，减少了索引的存储空间。

使用前缀索引是为了减少索引字段大小，可以增加一个索引页中存储的索引值，提高索引的查询速度。
在一些大字符串的字段作为索引时，使用前缀索引可以帮助我们减少索引项的大小。

覆盖索引优化

例如，考虑以下表结构：

CREATE TABLE users (
  id INT PRIMARY KEY,
  name VARCHAR(50),
  age INT,
  INDEX idx_name_age (name, age)
);

执行以下查询：

SELECT name, age FROM users WHERE name = 'Alice';

在这个查询中，name 和 age 都包含在索引 idx_name_age 中，因此可以直接从该索引的叶子节点获取所需数据，避免了回表操作。

覆盖索引是指SQL中query的所有字段，在索引B+Tree的叶子节点上都能找得到的那些索引，从二级索引中查询得到记录，而不需要通过聚簇索引查询获得，可以避免回表的操作。

主键索引最好是自增的。

• 如果使用自增主键，那么每次插入的新数据就会按顺序添加到当前索引节点的位置，不需要移动已有的数据，当页面写满，就会自动开辟一个新页面。
  因为每次插入一条新记录，都是追加操作，不需要重新移动数据，因此这种插入数据的方法效率非常高。
• 如果使用非自增主键，由于每次插入主键的索引值都是随机的，因此每次插入新的数据时，就可能会插入到现有数据页中间的某个位置，（将不得不移动其他数据来满足新数据的插入，甚至需要从一个页面复制数据到另外一个页面，我们将这种情况称为页分裂。页分裂还有可能造成大量的内存碎片，导致索引结构不紧凑）

防止索引失效

1 当我们使用左或者左右模糊匹配的时候，也就是like %xx 或者 like %xx%这两种方式都会造成索引实效

MySQL 的 B+ 树索引是按照列值的字典序（从左到右）进行排序的。在执行查询时，MySQL 利用这种有序性快速定位匹配的记录。

然而，当使用 LIKE '%xx' 或 LIKE '%xx%' 进行查询时，通配符 % 出现在字符串的开头，使得查询条件无法确定字符串的起始部分。这意味着 MySQL 无法利用索引的有序性来定位数据，只能对整个表进行扫描

当我们在查询条件中对索引列做了计算、函数、类型转换操作，这些情况下都会造成索引失效。

B+ 树索引存储的是列的原始值

联合索引要能正确使用 需要遵循最左匹配原则，也就是按照最左优先的方式进行索引的匹配，否则就会导致索引实效。

索引结构是一颗 B+ 树，非叶子节点存储的是最左那列的键值

在where子句中，如果在or前的条件列是索引列，而在or后的条件列不是索引列，那么索引会失效。

若 WHERE 子句中通过 OR 连接的两端，只有一侧是索引列，另一侧不是索引列；优化器会认为“既要走索引又要对非索引列全表扫描，反正都得扫一次”，于是直接放弃索引，全表扫描更省成本。