EF Core 6+MySQL TPH模式子类Count查询性能异常排查

核心问题原因 #

性能差异来自EF Core TPH（层次结构共用表）映射的默认SQL生成逻辑，和业务筛选逻辑、现有索引的业务字段部分无关：

• 调用基类Property仓储的CountAsync时，EF Core生成的SQL仅包含你传入的三个筛选条件：CountryId = 1、IsBlocked = false、IsPublic = true，完全匹配你已创建的业务索引，查询可以直接走索引完成计数，耗时不足1秒属于正常表现。
• 调用子类RealEstate仓储的CountAsync时，EF Core会自动追加TPH鉴别器列（Discriminator）的筛选条件，最终生成的SQL会额外带上Discriminator = 'RealEstate'的判断。

你之前创建的索引没有将EF Core自动生成的Discriminator列纳入索引字段，导致针对子类的查询无法命中现有联合索引完成覆盖计数，会触发回表扫描甚至全表匹配鉴别器值，100万数据量下耗时飙升到10秒是典型的索引不匹配特征。

验证方式 #

开启EF Core的SQL日志输出，提取两个查询生成的完整SQL语句，在MySQL Workbench中分别执行EXPLAIN分析执行计划：基类查询会命中你创建的业务索引，扫描行数等于实际符合条件的数据量；子类查询要么无法命中有效索引走全表扫描，要么扫描行数远大于实际符合条件的结果数。

修复方案 #

• 调整现有联合索引结构，将Discriminator列放在联合索引的最前列，后续按查询频次依次拼接CountryId、IsBlocked、IsPublic等常用筛选字段，让子类查询可以直接命中索引完成计数。
• 如果业务中基类、不同子类的查询场景占比接近，可以针对不同查询模式分别建对应联合索引，避免索引字段顺序不匹配导致的性能问题。
• 禁止为了绕过鉴别器条件，直接从基类DbSet查询后在内存中做子类类型过滤，该写法会拉取全量基类数据到内存再筛选，性能损耗会比索引不匹配更严重。

内容的提问来源于stack exchange，提问作者Amokachi