有两个用于测试数据的简化表，一个是goods_category，另一个是产品表。两个表是类别和产品之间的关系，即，一个类别可以与多个产品相对应。启动脚本如下。（testdb.sql）
我们知道，对于模糊的查询，该段落在左侧不使用。这是很好的理解，因为每个记录都可能匹配。只检查每个记录才能确定是否满足模糊匹配条件，例如：
MySQL文档指出，传递字符的末尾可用于索引，例如：
因此，对于以下数据，如果您使用模糊匹配，您可以使用索引吗？
看看结果：
您可以看到类型：全部，这意味着要扫描完整的表格。我们可以停下来思考。执行计划如何使用完整的表扫描模糊查询，该查询只能匹配一块数据。
答案是这里有一个特殊的下属线。我们知道，在MySQL中，下层线与单个字符匹配。因此，从理论上讲，需要检查以“女性”一词开头的产品以完成查询。“女性”在大多数产品表中说明了。因此，当完整桌扫描时，执行计划是正确的。LET使用该线路建立正义。
这取决于MySQL优化器查询成本的估计。如果索引的估计成本低于所有索引，则将使用索引。MySQL估计的估计行越来越大：
当前表的查询执行方法具有以下值，并且性能从好处到坏处：
行要执行查询。MySQL估计需要扫描的行数。这是MySQL基于表统计信息进行的估计值，它不是准确的值。此值应该是选择查询计划的MySQL查询优化器的关键指标之一。行是填写的潜在行数。按类型：
行与步行桌相连的数量。对于Exmple，如果是1000，则为50.00（50％），与后续表连接的行数为1000×50％= 500。
过滤表示满足查询条件的数据的数据百分比估计，最多100（所有行都符合条件）。使用行×纤毛以获取连接到下一表的行数。过滤= 50％，连接到下表的行数为500。
例如，MySQL优化器分析了几个执行计划的成本，并选择了最佳的执行计划。
然后，MySQL将使用其他条件的其他条件，即在哪里过滤上一行行的行数，例如上面的174行。如果没有其他条件，则除此索引字段条件外，归档为100；如果还有其他条件，MySQL将根据其他条件估算过滤值。估计当前有32条线符合条件，因此在应用过滤器后将保留这174条线中的18％。
行和过滤只是粗略的估计，有时估计相对较大。因此，它只能用作查询优化的参考。滤波= 100并不意味着您的索引是好的，并且较低的值不为一定意味着不良索引。
显示当前可以使用索引的查询。该列的数据是在优化过程中早期创建的，因此对于后续优化过程，某些索引可能毫无用处。
索引MySQL实际选择的索引
混合物的左侧，MySQL优化器不选择索引查询。无论是在右侧还是中间使用索引取决于成本的估计。如果估算了最终估计，MySQL认为比较表扫描具有成本效益，并且将选择索引查询。
原始：https：//juejin.cn/post/71022322222213362724