问下PolarDB的sql 代价预估为啥很不稳定呢？-云小二-阿里云

SELECT a.* FROM ( SELECT con.contentid, con.catid, cat.name AS catname, cat.abbr AS catabbr, con.modelid , con.title, con.subtitle, con.url AS info_url, con.tags AS tags, con.tags AS original_tags , CASE WHEN LOWER(LEFT(con.thumb, 4)) = ‘http’ THEN con.thumb ELSE CONCAT(‘https://upload.echemi.com/’, con.thumb) END AS thumb, con.published, con.pv FROM cmstop_content con INNER JOIN cmstop_category cat ON cat.catid = con.catid AND cat.first_parentid = ‘201’ AND FIND_IN_SET(‘204’, cat.parentids) INNER JOIN ( SELECT content_tag.contentid FROM cmstop_tag tag INNER JOIN cmstop_content_tag content_tag ON tag.tagid = content_tag.tagid WHERE tag.tag = ‘zyp-pd20150901274’ ) content_tag ON con.contentid = content_tag.contentid WHERE con.status = 6 AND con.modelid IN (1, 3, 4, 10) ORDER BY con.published DESC, con.contentid DESC LIMIT 1 ) a;问下这个sql 代价预估为啥很不稳定呢？

以下为热心网友提供的参考意见

PolarDB的SQL代价预估不稳定的原因可能有以下几点：

1. 数据量较大：当查询的数据量非常大时，代价预估可能会受到数据分布、索引等因素的影响，导致预估结果不准确。

2. 索引不足：如果查询中涉及的表没有合适的索引，那么代价预估可能会受到影响。例如，在这个例子中，如果没有为catid和contentid字段创建索引，那么代价预估可能会不准确。

3. 统计信息不准确：如果数据库的统计信息不准确，那么代价预估也可能会受到影响。这可能导致代价预估结果偏大或偏小。

4. 查询优化器选择：查询优化器在执行查询时，可能会根据当前的代价预估结果来选择不同的执行计划。如果优化器在选择执行计划时没有充分考虑到所有因素，那么代价预估结果可能会受到影响。

5. 硬件资源限制：如果数据库服务器的硬件资源有限，那么代价预估结果可能会受到硬件资源的限制。例如，如果内存不足，那么代价预估可能会受到影响。

为了提高代价预估的准确性，可以尝试以下方法：

1. 为涉及的表创建合适的索引，以提高查询性能。

2. 定期更新数据库的统计信息，以获得更准确的代价预估结果。

3. 调整查询优化器的参数，以找到更适合当前查询的计划。

4. 确保数据库服务器的硬件资源充足，以满足代价预估的需求。

以下为热心网友提供的参考意见

现在MySQL做代价估算会考虑in-memory指的是buffer-pool里面的热数据的比例，这个查询如果落在不同节点上，就可能有不同代价值。此回答整理自钉群“PolarDB 专家面对面 – 慢SQL索引选择优化器新特性”。

以下为热心网友提供的参考意见

PolarDB的SQL代价预估不稳定的原因可能有以下几点：

1. 统计信息不准确或过时：如果数据库中的表没有及时更新统计信息，或者统计信息收集的频率不够高，那么SQL优化器在进行代价预估时可能会使用不准确的数据，导致预估结果不稳定。

2. 执行计划选择策略：SQL优化器在选择最优执行计划时，可能会根据统计信息、表大小、索引等因素进行动态调整。这种策略在某些情况下可能会导致代价预估的波动。

3. 参数化查询：如果查询中使用了参数化查询，那么每次执行查询时，实际传入的参数值可能不同，从而导致执行计划和代价预估的变化。

4. 并发查询：如果有多个用户同时执行类似的查询，那么数据库可能需要为每个查询生成不同的执行计划，这也可能导致代价预估的不稳定。

针对以上原因，可以尝试以下方法来提高SQL代价预估的稳定性：

1. 定期更新统计信息：可以通过ANALYZE TABLE命令或者自动统计功能来更新统计信息。

2. 选择合适的索引：为表创建合适的索引可以提高查询性能，同时也有助于优化器更准确地进行代价预估。

3. 避免不必要的参数化查询：尽量减少使用参数化查询，以减少因参数值变化导致的执行计划和代价预估的波动。

4. 控制并发查询：合理分配查询资源，避免大量并发查询对数据库性能造成影响。