问题一：在PolarDB如果查询次数增加的话，是增加节点合算还是变更配置合算？
在PolarDB如果查询次数增加的话，是增加节点合算还是变更配置合算？一个节点2核4G。还是两个节点一核2G？两种方式有什么不同吗？提升配置可以查询得更快? 
参考回答：
建议直接开通serverless，更划算。
关于本问题的更多回答可点击原文查看：https://developer.aliyun.com/ask/584050
问题二：PolarDB这个问题怎么解决？
PolarDB这个问题怎么解决？以前在rds不是慢sql的全都变成慢sql了，调整固定最低pcu也没什么见效，只有大半pcu时见效。以前rds主库8核16G，拖两4核8G的只读只读，做了读写分离
参考回答：
你这个场景其实我推荐使用固定规格serverless。就是有一个基础规格，然后补上serverless的功能。不建议用纯serverless集群。8核16G RDS对应同规格的serverless应该是8 PCU。参考https://help.aliyun.com/zh/polardb/polardb-for-mysql/user-guide/enable-the-serverless-function-for-fixed-specification-clusters?spm=a2c4g.11186623.0.0.1cff71c7rA7OlE
关于本问题的更多回答可点击原文查看：https://developer.aliyun.com/ask/584049
问题三：PolarDB的pcu中cpu和内存指标是不是该分开换算控制？
PolarDB的pcu中cpu和内存指标是不是该分开换算控制？
固定最低pcu个数4后，实际加速效果，也不敢说好，并且也不会触发serverless的升级。
既然有LRU的机制，那还在serverless的基础上，控制内存，导致LRU基本失效了，不可能所有sql都刚在内存中。
再就是serverless的扩容颗粒度，比如高并发一波内存上了多个G,根据文档弹性时间=探测时间+决策时间+执行时间，负载下降内存就被释放了，业务高峰lru这些内存还没加载使用第二遍，就被释放了，全靠磁盘重新硬读了。
参考回答：
调整serverless的最小PCU配置，就可以控制serverless不会自动降配到过低的规格，buffer pool也可以保持固定规格的下限。在这个基础上，SQL的性能表现和buffer pool命中率有关，这个行为PolarDB和RDS不会有差异。你提到的LRU被淘汰，性能变差的场景，在RDS上是一样的。
关于本问题的更多回答可点击原文查看：https://developer.aliyun.com/ask/584048
问题四：在PolarDB这种情况应该怎么配置？
在PolarDB中，我们集群配置主从1~16pcu，比如innodb_buffer_pool_size，另外线上innodb_buffer_pool_size配置里面是在变动的，这种情况应该怎么配置？
参考回答：
Serverless 主要用于自动应对性能瓶颈，尤其是在宏观环境下的偶然或周期性的高并发情况，而不针对特定少数SQL查询的性能优化。对于你的场景，如果业务上对这条SQL的延迟有一定要求，可以选择调整serverless的最小PCU配置，来控制serverless不会自动降配到过低的规格。
关于本问题的更多回答可点击原文查看：https://developer.aliyun.com/ask/584047
问题五：PolarDB的这个是什么意思？!
PolarDB的这个[{DBNodeClassMemory1/4}-{DBNodeClassMemory3/4}] 是什么意思？ 
参考回答：
DBNodeClassMemory 这是指实例的规格内存，建议buffer pool设置的值在规格内存的1/4 - 3/4 之间。
关于本问题的更多回答可点击原文查看：https://developer.aliyun.com/ask/584046
