mysql不走索引怎么解决的

这事儿啊，得好好说说。
2 02 2 年，我在某个城市那会儿，遇到个问题，当时也懵了。
就是那个业务数据库，数据量那叫一个大，查询条件没建立索引，结果一查，全表的数据都出来了，不止2 5 %，简直都快一半了。
我当时就纳闷了，这怎么这么不精准呢？
后来我仔细一看，原来是索引失效了。
那统计数据，那可就完全不准确了。
索引这东西，它是有自我维护的能力，但是表内容变化太频繁，它就有点跟不上了。

再一看，查询条件还用了函数，在索引列上还做了运算，加减乘除，还有那个逻辑非，这可真是雪上加霜。
我那时候就想，这要是用索引，那得浪费多少资源啊，查询效率能高吗？
所以啊，后来我就建议，得优化查询条件，别在索引列上用函数，运算也得小心点。
这事儿，得好好处理，不然数据库那负担可就重了。
说起来，这数据库优化，还真是门学问呢。

我面试几乎必问：你设计索引的原则是什么？怎么避免索引失效？

2 02 3 年，我那个朋友在研究数据库设计时，遇到了不少关于索引的难题。
设计索引，得遵循几个原则，比如：
1 . 主键索引设计：自增主键比UUID更高效，因为自增主键能让MySQL快速定位新记录插入位置。
2 . 为频繁查询的字段建立索引：这能提高查询速度，特别是联合索引。
3 . 避免为“大字段”建立索引：大字段会增加索引占用空间和排序时间。
4 . 选择区分度大的列作为索引：区分度不高的字段不适合做索引。
5 . 尽量为ORDERBY和GROUPBY后面的字段建立索引：这可以避免排序和产生临时表。

但是，要避免索引失效，也有一些方法：
1 . 不要在条件中使用函数：函数操作会导致索引失效。
2 . 不要建立太多的索引：太多索引会增加MySQL负担。
3 . 频繁增删改的字段不要建立索引：频繁变化会影响性能。
4 . 避免使用OR关键字：使用OR会导致索引失效。
5 . 遵循联合索引的最左前缀原则：不遵循原则，索引会失效。
6 . 模糊查询避免以%开头：以%开头会导致索引失效。
7 . 避免索引列使用隐式转换：隐式转换会导致索引失效。

设计索引是一门学问，既要高效又要避免失效，得细心操作。
这部分我不确定，但我朋友现在好像找到了解决方法。
算了，你看着办吧。

mysql 数据库中对表中数据删除,重新添加数据索引不会重新开始,按原来索引自增

上周有个客人问我，如果在一个自增主键的表中删除了id=3 的数据，下一条数据的id会如何变化。
这个问题其实挺有意思的，因为涉及到数据库的自动增长和主键的设计。

首先，如果id是自增主键，那么它的值是自动递增的。
当你删除id=3 的数据后，数据库会尝试将下一条数据的id设置为4 但是，如果表中没有id=4 的数据，比如id=3 后面直接是id=5 ，那么下一条数据的id就会变成5 ，而不是4
但是，如果你想要id=3 删除后，下一条数据的id直接变成3 ，这就比较复杂了。
通常情况下，这是不可能的，因为自增主键的设计就是为了保持数据的连续性和唯一性。

除非你手动干预，比如使用一些特定的数据库命令。
比如，你可以使用以下SQL语句来尝试达到这个效果：
sql DELETE FROM your_table WHERE id = 3 ; UPDATE your_table SET id = id
1 WHERE id > 3 ;
这样的操作实际上是在删除id=3 的数据后，将所有id大于3 的记录的id减1 ，从而让id=3 的空缺被填补。

但这种方法有两个问题：一是它破坏了id的连续性，可能会导致数据的不一致；二是它不是数据库的标准操作，可能会因为数据库的不同而无法使用。

还有一种极端的做法，就是使用TRUNCATE TABLE命令，这个命令会删除表中的所有数据，并且重置自增主键的计数器。
但这种方法会删除表中的所有数据，所以通常不推荐。

总之，如果你想保持id的连续性，最好的做法是在设计数据库时就考虑好数据的插入和删除策略。
如果真的需要id=3 删除后，下一条数据的id变成3 ，可能需要手动操作，但这样做要谨慎，以免造成数据不一致。
反正你看着办吧。
我还在想这个问题，看看有没有更好的解决方案。