索引
这个现象可能是由于数据量较小时，添加索引会导致MySQL优化器选择不同的执行计划，导致查询变慢。当数据量增加时，索引可以更好地支持查询，因此查询性能才能够得到提高。
当数据表比较小的时候，索引可能不会为查询带来优势，甚至会拖慢查询速度。这是因为，MySQL优化器会根据查询数据的大小和表结构以及索引的情况来选择执行计划。如果数据量较小，可能会选择全表扫描来进行查询，而不是使用索引。
但是，当数据量逐渐增加时，MySQL优化器会更倾向于使用索引来加速查询，这是因为全表扫描会随着数据量的增加而变得越来越慢，而索引可以更快地定位到需要查询的数据。
因此，在设计数据库时，通常需要根据实际情况进行索引设计。对于数据量较小的表，可能不需要创建过多的索引，可以通过优化其他方面的查询条件来提高查询性能。而对于数据量较大的表，多创建一些合理的索引是很有必要的，可以提高查询速度，提升数据库的性能。
索引字段在满足业务需求的同时尽量保持小
应该在索引字段的长度满足业务需求的同时尽量保持小。因为在索引中存储的数据量越小，查询时扫描的数据量也就越小，查询速度也就越快。
如果字符串类型的索引字段长度太长，将会导致索引树分支过多，占用更多的存储空间，在查询时也会降低查询的速度和效率，因此可以采取以下措施：
- 如果索引字段长度较长，可以尝试使用前缀索引，只对索引的前几个字符进行索引，这样可以节省存储空间，同时也可以加快查询速度。
- 如果业务需求不允许使用前缀索引，则需要权衡长度和查询效率之间的关系，选取合适的索引字段长度。
综上所述，索引字段长度不应过长，应该根据业务需求选择合适的长度，也可尝试使用前缀索引来优化查询效率。
测试结果：varchar(100) = 0.78;varchar(20)=0.45
多个索引时，最左匹配原则
$\textcolor{green}{在多个索引的情况下，根据最左匹配原则，应该优先将常用的查询条件放在索引的最左侧，在此基础上再考虑其他查询条件。} $
具体来说，假设有以下查询条件：
- A=1
- B=2
- C=3
如果经常以 A、B、C 依次作为查询条件进行查询，那么最佳的索引顺序应该是 ABC，这样可以让索引最大限度地发挥作用，提高查询效率。如果查询条件的使用频率不同，那么索引的排列顺序也可能需要做出调整。
此外，还需要注意以下几点：
- 防止冗余索引：索引越多，写入时的维护成本就越高，因此需要避免创建大量冗余的索引。
- 索引的选择性越高，效果越好：索引的选择性指索引列的离散度，如果索引列的相同值较少，那么索引就会更有效。举个例子，如果索引的列中有 A、B、C、D 四个值，但是其中 A 的占比很高，那么就应该将 A 放在索引的最左侧。
综上所述，根据最左匹配原则，应该根据查询条件的使用频率和索引选择性来保证索引的优先级，在决定索引的排列顺序时需要权衡多方面因素，包括查询效率、索引的选择性、索引的数量等，以达到一个最佳的索引方案。
除了最左匹配原则，还有以下几个方面需要注意：
- 联合索引的顺序：如果存在联合索引，需要根据最左匹配原则来选择索引列的顺序，并考虑每个索引列的选择性，让选择性最高的列放在最左侧，这样可以让查询效率更高。
- 避免重复的索引：重复索引会浪费存储空间，在更新数据时会降低写入性能，因此需要避免创建重复的索引。
- 为复合索引减少索引列：复合索引中的索引列越多，查询效率就越低，因此需要选择最少的索引列来满足业务需求。
- 不要将所有列都加入索引：虽然索引可以提高查询速度，但是将所有列都加入索引会浪费存储空间，降低索引写入性能，因此需要只对最常用的列或者最有选择性的列进行索引。
索引第一次查询和第二次查询速度差异较大原因
第一次查询耗时0.6秒，第二次查询仅耗时0.2秒
第一次查询需要从磁盘中读取索引结构和数据页信息，因此查询的耗时较长。而第二次查询时，索引结构和数据页信息已经被读取到内存中，并且可能已经被缓存到更快的存储设备中，因此查询的耗时就会更短。可以说，索引的加速作用不仅限于提高第二次查询的速度，而且还可以加速第一次查询的速度。
需要注意的是，索引的缓存是一个基于内存的过程。如果索引结构非常大，无法完全缓存在内存中，那么就可能需要在查询时从磁盘中读取索引结构的某些部分，这也会影响查询的速度。因此，在创建索引时需要考虑索引的大小和内存大小之间的平衡，以达到最优的性能和效率。
char和varchar
char和varchar都是表示字符串类型的数据。它们之间的主要区别在于char类型的存储空间是固定的，而varchar类型的存储空间是可变的。
在创建表时，如果我们知道某个字段的长度是固定的，例如身份证号、邮政编码等，那么使用char类型会更加合适。
$\textcolor{green}{因为char类型的存储空间是固定的，存储和查询的效率更高，而且对于固定长度字段的优化也更容易实现。同时，在对固定长度字段进行插入和更新操作时，}$
$\textcolor{green}{也不需要进行额外的空间分配和释放操作。}$
而当我们不确定某个字段的长度时，例如用户名、地址等，使用varchar类型会更加合适。因为varchar类型的存储空间是可变的，可以根据实际需要分配空间。这种类型的字符串可以节省存储空间，同时也可以更加灵活地应对复杂的业务场景。
总的来说，在创建表时，使用char类型比varchar类型更加适合既定长度的字符串，因为char类型的效率更高，更加适用于固定长度字段的优化。而在不确定长度的情况下，使用varchar类型更加灵活和节省存储空间。不同场景下选取适当的数据类型可以提高数据库的性能。