问题一：PolarDB这个灵敏度的时间 控制台可以调整到10秒以下吗？
PolarDB这个灵敏度的时间 控制台可以调整到10秒以下吗？
参考回答：
控制台还不支持。
关于本问题的更多回答可点击原文查看：
https://developer.aliyun.com/ask/595170
问题二：PolarDB这个类型sql为什么并发量不高能把AP节点cpu打的很高呢？
PolarDB这个类型sql为什么并发量不高能把AP节点cpu打的很高呢？ SELECT sdt.produce_id, sdt.customer_id, sdt.company_name AS company_name_m, sdt.prefix_domain_name, sdt.products_id , sdt.products_url_name, sdt.cas_no, sdt.produce_name, sdt.produce_url_name, sdt.goods_picture_s , sdt.goods_picture_m AS goods_picture, sdt.goods_picture_b, sdt.complete_flag, sdt.hot_flag, sdt.main_flag , sdt.grade_name, sdt.content, sdt.package_name, sdt.n_price_type, sdt.n_price_trade_term_type , sdt.n_price_trade_term_text, sdt.n_price, sdt.n_price_unit, sdt.n_price_currency, sdt.n_price_currency_symbol , CASE WHEN CEILING(IFNULL(sdt.n_min_price, 0)) = 0 THEN '0' WHEN sdt.n_price_end_date < CURRENT_DATE() THEN '0' ELSE '1' END AS n_pending_flag, sdt.activity_id, sdt.activity_type, sdt.a_price_trade_term_type, sdt.a_price_trade_term_text , sdt.a_price, sdt.a_price_unit, sdt.a_price_currency, sdt.a_price_currency_symbol FROM t_e_all_produce_seller_activity sdt LEFT JOIN ( SELECT stpr.id, stpr.produce_id FROM t_e_seller_tag_produce stpr INNER JOIN t_e_seller_tag stag ON stag.customer_id = 'us20220607140012825' AND IFNULL(stag.is_website_show, '') != '1' AND IFNULL(stag.delflag, '') != '1' WHERE stpr.tag_id = stag.tag_id AND IFNULL(stpr.is_website_show, '') != '1' AND IFNULL(stpr.delflag, '') != '1' ) tagp ON tagp.produce_id = sdt.produce_id WHERE sdt.customer_id = 'us20220607140012825' AND IFNULL(sdt.delflag, '') != '1' AND tagp.id IS NULL ORDER BY sdt.complete_flag DESC, sdt.main_flag DESC, sdt.activity_id DESC, sdt.hot_flag DESC, n_pending_flag DESC, sdt.produce_update_date DESC LIMIT 24;
参考回答：
列存节点上的SQL都是并发还行的，单SQL都有可能把CPU用的很满。你们如果没有慢查CPU高可以不用关注。如果有慢查的话就需要升级一下CPU或者使用Serverless动态弹性了。serverless 可以在已购实例上开启，不会出现闪断等可用性影响。开启后，压力上升会自动增加规格，压力下降自动降低规格到原始规格。开启方式可以参考文档：
关于本问题的更多回答可点击原文查看：
https://developer.aliyun.com/ask/595164
问题三：PolarDB这Cpu 和内存一直飙升不下降是什么原因？
PolarDB这Cpu 和内存一直飙升不下降是什么原因？ 
参考回答：
PolarDB的CPU和内存使用率持续高企可能是由于多种原因造成的，以下是一些可能的原因及相应的解决方法：
- 业务量上涨：随着业务量的增长，数据库需要处理更多的请求，这可能导致CPU使用率升高。解决方案可能包括优化查询语句、增加只读副本以分散读取压力或升级硬件规格。
- 慢查询：如果存在慢查询，即执行时间较长的SQL语句，它们会占用较多的CPU资源。通过PolarDB控制台的慢SQL菜单查看慢查询情况，并对其进行分析优化。例如，如果发现某个查询的扫描行数远远大于返回行数，可能是因为缺少合适的索引。
- 内存管理不当：如果查询使用了过多的内存，可能会导致内存使用率飙升。PolarDB-X的内存管理机制旨在控制每个查询的内存限制，预防内存溢出和查询间的内存争抢。解决方案可能包括调整内存分配策略或优化查询以减少内存使用。
- 配置问题：某些配置设置可能导致PolarDB在不需要时也保持高资源使用率。检查和调整相关配置可能有助于解决问题。
- 内核模块预留内存：在PolarDB Serverless集群中，为了能够快速弹升资源，部分内核模块可能会预留一部分内存空间，这可能导致即使在低负载时内存使用率也显示为较高。
- 系统自动扩展：在某些情况下，PolarDB可能会自动扩展以应对潜在的工作负载，这可能会暂时导致资源使用率上升。
- 其他用户或进程：系统中的其他用户或后台进程也可能占用大量的CPU和内存资源。
综上所述，PolarDB的CPU和内存使用率持续高企可能是由多种因素导致的。为了解决这些问题，建议监控PolarDB的性能指标，定期检查慢查询日志，优化查询语句和索引，合理配置内存和CPU资源，以及考虑业务量的变化和系统的自动扩展行为。如果问题依然无法解决，可以联系PolarDB的技术支持团队进行进一步的分析和协助。
关于本问题的更多回答可点击原文查看：
https://developer.aliyun.com/ask/595163
问题四：PolarDB备份下载链接只有一天有效吗？能不能加时间长点，如果一天下载不完怎么办？
PolarDB备份下载链接只有一天有效吗？能不能加时间长点，如果一天下载不完怎么办？ 
参考回答：
往oss放，再慢慢下。
关于本问题的更多回答可点击原文查看：
https://developer.aliyun.com/ask/595162
问题五：在PolarDB相同的sql 通过代理地址执行百秒 通过主库地址查询秒级 有可能是什么原因？
在PolarDB相同的sql 通过代理地址执行百秒 通过主库地址查询秒级 有可能是什么原因？pi-2ze22jk4fo234eo77 执行节点 只读 数据是热数据。sql.txt。SELECT
msm.id AS caId,
msm.traineeMajorCode AS majorCode,
msm.NAME,
msm.account AS loginName,
msm.gendercode AS genderCode,
msm.identificationnumber AS IDCard,
msm.cellphone AS phoneNumber,
CONCAT_WS( '-', REPLACE ( dic1.dictionaryName, '角色', '' ), dic2.dictionaryName, dic3.dictionaryName ) AS humanTypeName,
msm.traineeyear AS referenceYear,
msm.specialitytitlecode AS specialitytitlecode,
hr_child.roleName AS allroles,
hd_child.departmentName AS departmentName,
CONCAT_WS( ',', sub1.majorName ) AS majorName,
m.id AS memberId
FROM
em_uums.t_institute mst
INNER JOIN em_uums.t_human_institute thi ON mst.id = thi.instituteId
INNER JOIN em_uums.t_human msm ON msm.id = thi.humanId
LEFT JOIN (
SELECT
hr.humanId,
GROUP_CONCAT( r.roleName ) AS roleName,
GROUP_CONCAT( hr.roleCode ) AS roleCode
FROM
em_uums.t_human_role hr
LEFT JOIN em_uums.t_role r ON r.roleCode = hr.roleCode
AND r.productCode = '20300'
WHERE
hr.instituteId = 'b2fd4660a03d45f7814345beefbc4bed'
AND hr.productCode = '20300'
GROUP BY
hr.humanId
) hr_child ON hr_child.humanId = thi.humanId
LEFT JOIN (
SELECT
hd.humanId,
GROUP_CONCAT( d.name ) AS departmentName,
GROUP_CONCAT( hd.departmentId ) AS departmentId
FROM
em_uums.t_human_department hd
LEFT JOIN em_uums.t_department d ON d.id = hd.departmentId
WHERE
hd.instituteId = 'b2fd4660a03d45f7814345beefbc4bed'
GROUP BY
hd.humanId
) hd_child ON hd_child.humanId = thi.humanId
LEFT JOIN em_uums.t_major sub1 ON sub1.majorCode = msm.traineeMajorCode
LEFT JOIN ex_t_member m ON m.caid = msm.id
LEFT JOIN em_uums.t_human_personneltype hp ON hp.humanId = msm.id
LEFT JOIN em_uums.t_dictionary dic1 ON dic1.dictionaryCode = msm.humanTypeCode
AND dic1.parentDictionaryCode = 'HumanType'
AND dic1.isDelete = '0'
LEFT JOIN em_uums.t_dictionary dic2 ON dic2.dictionaryCode = msm.personnelTypeCodes
AND dic2.parentDictionaryCode = 'PersonnelTypeCode'
AND dic2.isDelete = '0'
LEFT JOIN em_uums.t_dictionary dic3 ON dic3.dictionaryCode = msm.idtypeCode
AND dic3.parentDictionaryCode = 'IdType'
AND dic3.isDelete = '0'
WHERE
mst.id = 'b2fd4660a03d45f7814345beefbc4bed'
AND mst.deleted = '0'
AND ( 0 = 1 OR msm.NAME LIKE CONCAT( '%', '花卉', '%' ) )
AND msm.id NOT IN (
SELECT
temp2.caid
FROM
ex_t_exammember AS temp1
INNER JOIN ex_t_member AS temp2 ON temp1.memberid = temp2.id
AND temp1.paperid = '00000000609cf3bf0160d70ed92b62b3'
AND temp1.STATUS != '1'
)
GROUP BY
msm.id
ORDER BY
CONVERT ( msm.name USING GBK ) ASC
参考回答：
可能的原因有以下几点：
- 代理地址和主库地址的网络延迟不同，导致查询速度差异较大。可以通过ping命令或者traceroute命令检查网络延迟情况。
- 代理地址所在的服务器性能较低，导致查询速度较慢。可以查看服务器的CPU、内存等资源使用情况，以及磁盘I/O等指标。
- 数据库中的数据量较大，导致查询速度较慢。可以通过查看数据库表的大小、索引情况等来分析数据量是否较大。
- SQL语句中存在性能瓶颈，导致查询速度较慢。可以通过查看SQL执行计划、慢查询日志等来分析SQL语句的性能问题。
- 数据库中的锁竞争较为激烈，导致查询速度较慢。可以通过查看数据库的锁等待情况来分析锁竞争情况。
关于本问题的更多回答可点击原文查看：
