问题一：PolarDB中mysql我强制两表用hash join . 用BNL() hint无效。怎么回事？
PolarDB中 mysql 我强制两表用hash join . 用BNL() hint无效， 8.0.35版本，我想要这个关联也走hash join，可以实现吗？
参考回答：
在PolarDB中，MySQL不支持直接使用HASH JOIN。但是，您可以尝试以下方法来实现类似的效果：
- 将其中一个表的列转换为哈希值，然后使用这个哈希值进行连接操作。例如，您可以将一个表的某个列（如id）转换为哈希值，然后在另一个表中查找具有相同哈希值的记录。
- 使用其他数据库引擎，如Oracle或PostgreSQL，它们支持HASH JOIN。
- 如果可能的话，尝试优化查询语句，减少JOIN操作的次数，或者将数据分片存储在不同的数据库实例上，以提高查询性能。
关于BNL() hint无效的问题，可能是因为您的PolarDB版本不支持该hint。建议您查阅PolarDB官方文档，了解当前支持的hint和它们的用法。
关于本问题的更多回答可点击原文查看：
https://developer.aliyun.com/ask/590585
问题二：在PolarDB索引的cardinality都是11117为什么join 评估的行数只有285？
在PolarDB索引的cardinality都是 11117 为什么join 评估的行数只有 285？ 
参考回答：
在数据库优化器中，JOIN操作的成本估算和执行计划生成是非常复杂的，涉及到多个因素，包括但不限于索引的选择性（Cardinality）、表的实际数据分布、统计信息的准确性、JOIN条件的筛选力度、数据冗余、查询过滤条件、JOIN类型（如Nested Loop Join、Hash Join、Merge Join等）等因素。
尽管索引的Cardinality（基数）表示的是索引列中不重复值的数量，但它只是估计行数的一个依据，而非精确的行数。在JOIN操作中，特别是当JOIN条件不仅仅是基于索引列时，优化器还会综合考虑JOIN条件带来的过滤效果，即通过JOIN条件能匹配多少行。
假设PolarDB数据库中，即使两张表参与JOIN的索引Cardinality均为11117，但在JOIN条件的作用下，可能只有部分行才能相互匹配。也就是说，实际执行JOIN操作时，可能只有285行符合JOIN条件的要求。数据库优化器正是基于现有的统计信息和JOIN条件做出这一估算，以制定最优的执行计划。
如果在具体场景中遇到这种情况，建议通过以下方式进行排查和优化：
- 检查JOIN条件是否足够严格，是否有效地缩小了结果集。
- 查看数据库的统计信息是否准确且是最新的，过时的统计信息可能导致估算偏差。
- 使用
EXPLAIN或ANALYZE等工具查看优化器如何估算JOIN成本，并查看执行计划详情。 - 更新统计信息，确保数据库能够获得最新的数据分布情况。
- 如果估算严重偏离实际情况，可能需要手动调整JOIN策略，或者采用hint等方式指导优化器选择合适的执行计划。
关于本问题的更多回答可点击原文查看：
https://developer.aliyun.com/ask/590577
问题三：请问 BNL这个hint polardb废弃了吗？
请问 BNL这个hint polardb废弃了吗？
参考回答：
没有，和社区版 MySQL 一致的。
关于本问题的更多回答可点击原文查看：
https://developer.aliyun.com/ask/590575
问题四：在PolarDB用一键诊断，有条sql如图，可是我的程序代码里并没有执行过这个sql，为什么？
在PolarDB用一键诊断，有条sql如图，可是我的程序代码里并没有执行过这个sql，这是什么原因呢？ 
参考回答：
这可能是你连接库或者框架中的语句。有setAutoCommit， commit，rollback之类的事务相关调用。
关于本问题的更多回答可点击原文查看：
https://developer.aliyun.com/ask/590572
问题五：PolarDB中oss 的进度我怎么看？
PolarDB中oss 的进度我怎么看？ 
这两个表里面也没有数据
参考回答：
在PolarDB中查看OSS进度，可以通过如下步骤进行操作：首先，您需要在RO节点上执行/*force_node='pi-bpxxxxxxxx'*/ flush tables命令，以读取到最新的OSS server信息。然后，您可以在INFORMATION_SCHEMA.IMCI_ASYNC_DDL_STATS表中查看列存索引从行存恢复数据或者通过异步DDL构建列存索引数据的过程，主要用于查看构建中的执行速度和任务进度。此外，当您查询OSS外部表中的历史归档数据时，PolarDB PostgreSQL版默认将启动一个进程查询OSS外表对应的全量数据，其本质上也是单进程下载的网络访问模式。而ePQ优化器能够产生多进程并行查询OSS外部表的执行计划，ePQ执行器将在多个计算节点上启动多个进程并行查询OSS外部表。这种方式可以提高查询效率，特别是在归档数据量非常大时。
关于本问题的更多回答可点击原文查看：
