TiDB~查询

一、查询配置

为了满足不同的业务需求，我们计划配置至少三个TiDB-SERVER实例。其中，两个实例将专用于程序访问，以确保应用程序的顺畅运行和高效数据库交互。第三个实例则独立用于用户查询，以分离业务负载并优化性能。对于负责用户查询的TiDB实例，我们将实施严格的SQL监控。尽管在TiDB服务器层进行了资源隔离，但由于共享底层的TiKV存储，用户查询仍可能对集群整体稳定性产生影响。因此，一旦监控到查询负载超过预设阈值，系统将自动终止这些查询，以维护整个集群的健康状态。

二、 统计信息不准确

索引选择性错误：索引的选择性是指索引列中不同值的数量与表行数的比率。如果 TiDB 对索引选择性的估算不准确，可能会导致优化器错误地选择或避免使用某个索引。使用 ANALYZE 命令定期更新表的统计信息，以确保它们与实际数据保持一致。

三、内存溢出（OOM）处理

过滤慢日志：使用命令 cat tidb.log | grep "expensive_query" 来过滤慢日志。在审查这些日志时，应关注以下几点：

                   1、执行时间：查询执行的总时间。

                    2、发生时间：查询开始执行的时间点。

                    3、占用内存大小：查询过程中消耗的内存量，特别关注占用内存大的查询。

                    请注意，即使查询未完成或被中断，相关信息也可能被记录在日志中，因为日志是实时更新的。

确定重启时间：

            通过命令 cat tidb.log | grep 'Welcome to TiDB' 可以过滤出TiDB服务器的重启事件，帮助定位问题发生前后的时间趋势。

查找OOM相关的SQL语句：

     使用命令 cat /data/tidb-deploy/tidb-4000/log/tidb.log | grep 'OOM' 来查找与内存溢出相关的日志条目。这些条目通常会包含导致OOM的具体SQL语句和执行时间。

     对于分析OOM问题，还可以考虑使用go tool pprof来分析heap文件，以获取更详细的内存使用情况。

内存使用趋势分析：

     利用Grafana等工具监控TiDB服务器的内存使用趋势，有助于定位内存占用异常的时间段。

Dashboard SQL分析：

      通过TiDB Dashboard的SQL分析功能，可以按照内存使用量对慢日志进行排序，快速找到内存消耗最大的查询。

流量可视化与热点表定位：

      利用TiDB Dashboard的流量可视化功能，可以直观地展示数据访问模式，帮助定位可能的热点表。

三 OOM原因分析：

在TiDB中，OOM问题可能由以下原因导致：

1、内存消耗大的SQL查询：某些查询可能因为数据处理量大或执行计划不优而导致大量内存消耗。

2、高并发SQL查询：大量的并发查询可能在短时间内耗尽可用内存。

3、CDC版本BUG：某些版本的Change Data Capture（CDC）组件可能存在BUG，导致内存泄露或不正常的内存消耗。

4、慢查询版本BUG：在某些情况下，TiDB的慢查询日志功能本身可能存在BUG，导致内存泄露或其他问题。

5、 其他原因：除了上述原因外，TiDB服务器的重启并不一定总是由OOM引起，还可能是其他原因如配置更改、系统维护等。