## 1. 环境信息
– **TiDB版本**：6.1.0
– **表结构**：test.users表，包含1000万行数据
– **索引情况**：无索引
– **操作系统**：Oracle Linux 9.3

## 2. 故障现象
– **SQL执行时间**：执行时间超过10秒
– **系统负载**：数据库CPU使用率达到100%
– **应用响应**：应用程序响应缓慢

## 3. 故障分析
– **SQL语句**：
“`sql
SELECT * FROM test.users WHERE age > 30;
“`
– **执行计划**：
“`
+————————-+———-+———–+—————+——————————–+-
| id | estRows | task | access object | operator info |
+————————-+———-+———–+—————+——————————–+-
| TableReader_7 | 3333333 | root | | data:Selection_6 |
| └─Selection_6 | 3333333 | cop[tikv] | | gt(test.users.age, 30) |
| └─TableFullScan_5 | 10000000 | cop[tikv] | table:users | keep order:false, stats:pseudo |
+————————-+———-+———–+—————+——————————–+-
“`
– **原因**：没有为age列创建索引，导致全表扫描

## 4. 解决方案
– **步骤1**：添加索引
“`sql
CREATE INDEX idx_age ON test.users(age);
“`

– **步骤2**：验证索引效果
“`sql
EXPLAIN SELECT * FROM test.users WHERE age > 30;
“`
– **执行计划**：
“`
+————————-+———-+———–+————————+———————————–+-
| id | estRows | task | access object | operator info |
+————————-+———-+———–+————————+———————————–+-
| IndexReader_6 | 3333333 | root | | index:IndexScan_5 |
| └─IndexScan_5 | 3333333 | cop[tikv] | table:users, index:idx_age | range:(30, +inf), keep order:false |
+————————-+———-+———–+————————+———————————–+-
“`

– **步骤3**：测试执行时间
“`sql
SELECT /*+ time */ * FROM test.users WHERE age > 30 LIMIT 1000;
“`
– **执行时间**：从10秒以上降至0.1秒以下

## 5. 预防措施
– **建立索引规范**：为频繁查询的列创建索引
– **定期检查慢SQL**：定期分析慢SQL，发现全表扫描
– **使用执行计划**：在开发阶段分析执行计划，避免全表扫描
– **监控索引使用情况**：监控索引的使用情况，及时优化

## 1. 环境信息
– **TiDB版本**：6.1.0
– **表结构**：test.orders表和test.order_items表
– **数据量**：orders表100万行，order_items表1000万行
– **操作系统**：Oracle Linux 9.3

## 2. 故障现象
– **SQL执行时间**：执行时间超过30秒
– **系统负载**：数据库CPU和内存使用率高
– **应用响应**：应用程序超时

## 3. 故障分析
– **SQL语句**：
“`sql
SELECT o.order_id, o.customer_id, SUM(oi.quantity * oi.price) AS total_amount
FROM test.orders o
JOIN test.order_items oi ON o.order_id = oi.order_id
WHERE o.order_date BETWEEN ‘2023-01-01’ AND ‘2023-12-31’
GROUP BY o.order_id, o.customer_id
ORDER BY total_amount DESC
LIMIT 100;
“`
– **执行计划**：
“`
+——————————–+———-+———–+————————+———————————–+-
| id | estRows | task | access object | operator info |
+——————————–+———-+———–+————————+———————————–+-
| Sort_8 | 100 | root | | sort:total_amount DESC |
| └─Limit_7 | 100 | root | | limit:100 |
| └─HashAgg_9 | 1000000 | root | | group by:o.order_id, o.customer_id, aggregate:sum(oi.quantity * oi.price) |
| └─HashJoin_10 | 10000000 | root | | inner join, equal:[o.order_id, oi.order_id] |
| ├─TableReader_14 | 1000000 | root | | data:Selection_13 |
| │ └─Selection_13 | 1000000 | cop[tikv] | | between(o.order_date, 2023-01-01, 2023-12-31) |
| │ └─TableFullScan_12 | 1000000 | cop[tikv] | table:o | keep order:false, stats:pseudo |
| └─TableReader_16 | 10000000 | root | | data:TableFullScan_15 |
| └─TableFullScan_15 | 10000000 | cop[tikv] | table:oi | keep order:false, stats:pseudo |
+——————————–+———-+———–+————————+———————————–+-
“`
– **原因**：查询包含表连接、聚合和排序操作，且没有使用索引

## 4. 解决方案
– **步骤1**：添加索引
“`sql
— 为orders表的order_date列添加索引
CREATE INDEX idx_order_date ON test.orders(order_date);
— 为order_items表的order_id列添加索引
CREATE INDEX idx_order_id ON test.order_items(order_id);
“`

– **步骤2**：优化SQL语句
“`sql
SELECT o.order_id, o.customer_id, SUM(oi.quantity * oi.price) AS total_amount
FROM test.orders o
JOIN test.order_items oi ON o.order_id = oi.order_id
WHERE o.order_date BETWEEN ‘2023-01-01’ AND ‘2023-12-31’
GROUP BY o.order_id, o.customer_id
ORDER BY total_amount DESC
LIMIT 100;
“`

– **步骤3**：验证优化效果
“`sql
EXPLAIN SELECT o.order_id, o.customer_id, SUM(oi.quantity * oi.price) AS total_amount
FROM test.orders o
JOIN test.order_items oi ON o.order_id = oi.order_id
WHERE o.order_date BETWEEN ‘2023-01-01’ AND ‘2023-12-31’
GROUP BY o.order_id, o.customer_id
ORDER BY total_amount DESC
LIMIT 100;
“`
– **执行计划**：
“`
+——————————–+———-+———–+————————+———————————–+-
| id | estRows | task | access object | operator info |
+——————————–+———-+———–+————————+———————————–+-
| Sort_8 | 100 | root | | sort:total_amount DESC |
| └─Limit_7 | 100 | root | | limit:100 |
| └─HashAgg_9 | 1000000 | root | | group by:o.order_id, o.customer_id, aggregate:sum(oi.quantity * oi.price) |
| └─HashJoin_10 | 10000000 | root | | inner join, equal:[o.order_id, oi.order_id] |
| ├─IndexReader_14 | 1000000 | root | | index:IndexScan_13 |
| │ └─IndexScan_13 | 1000000 | cop[tikv] | table:o, index:idx_order_date | range:[2023-01-01, 2023-12-31], keep order:false |
| └─IndexReader_16 | 10000000 | root | | index:IndexScan_15 |
| └─IndexScan_15 | 10000000 | cop[tikv] | table:oi, index:idx_order_id | keep order:false, stats:pseudo |
+——————————–+———-+———–+————————+———————————–+-
“`

– **步骤4**：测试执行时间
“`sql
SELECT /*+ time */ o.order_id, o.customer_id, SUM(oi.quantity * oi.price) AS total_amount
FROM test.orders o
JOIN test.order_items oi ON o.order_id = oi.order_id
WHERE o.order_date BETWEEN ‘2023-01-01’ AND ‘2023-12-31’
GROUP BY o.order_id, o.customer_id
ORDER BY total_amount DESC
LIMIT 100;
“`
– **执行时间**：从30秒以上降至2秒以下

## 5. 预防措施
– **优化查询结构**：简化复杂查询，避免多层嵌套
– **合理使用索引**：为连接列和过滤列创建索引
– **限制结果集**：使用LIMIT限制返回数据量
– **使用物化视图**：对于复杂查询，使用物化视图预计算结果

## 1. 环境信息
– **TiDB版本**：6.1.0
– **表结构**：test.users表，包含500万行数据
– **索引情况**：name列有索引
– **操作系统**：Oracle Linux 9.3

## 2. 故障现象
– **SQL执行时间**：执行时间超过5秒
– **系统负载**：数据库CPU使用率高
– **应用响应**：应用程序响应缓慢

## 3. 故障分析
– **SQL语句**：
“`sql
SELECT * FROM test.users WHERE LOWER(name) = ‘test’;
“`
– **执行计划**：
“`
+————————-+———+———–+—————+——————————–+-
| id | estRows | task | access object | operator info |
+————————-+———+———–+—————+——————————–+-
| TableReader_7 | 2500000 | root | | data:Selection_6 |
| └─Selection_6 | 2500000 | cop[tikv] | | eq(lower(test.users.name), “test”) |
| └─TableFullScan_5 | 5000000 | cop[tikv] | table:users | keep order:false, stats:pseudo |
+————————-+———+———–+—————+——————————–+-
“`
– **原因**：在索引列上使用了LOWER函数，导致索引失效，产生全表扫描

## 4. 解决方案
– **步骤1**：优化SQL语句
“`sql
— 优化前：使用函数导致索引失效
SELECT * FROM test.users WHERE LOWER(name) = ‘test’;

— 优化后：避免在索引列上使用函数
SELECT * FROM test.users WHERE name = ‘test’;
“`

– **步骤2**：如果需要不区分大小写查询
“`sql
— 创建不区分大小写的索引
CREATE INDEX idx_name_ci ON test.users((LOWER(name)));

— 使用索引
SELECT * FROM test.users WHERE LOWER(name) = ‘test’;
“`

– **步骤3**：验证优化效果
“`sql
EXPLAIN SELECT * FROM test.users WHERE name = ‘test’;
“`
– **执行计划**：
“`
+————————-+———+———–+————————+———————————–+-
| id | estRows | task | access object | operator info |
+————————-+———+———–+————————+———————————–+-
| IndexReader_6 | 1 | root | | index:IndexScan_5 |
| └─IndexScan_5 | 1 | cop[tikv] | table:users, index:idx_name | range:[“test”, “test”], keep order:false |
+————————-+———+———–+————————+———————————–+-
“`

– **步骤4**：测试执行时间
“`sql
SELECT /*+ time */ * FROM test.users WHERE name = ‘test’;
“`
– **执行时间**：从5秒以上降至0.01秒以下

## 5. 预防措施
– **避免在索引列上使用函数**：会导致索引失效
– **使用表达式索引**：如果需要在索引列上使用函数，创建表达式索引
– **标准化数据**：在插入数据时标准化数据格式，避免查询时使用函数
– **定期检查索引使用情况**：监控索引的使用情况，及时发现索引失效问题

## 1. 环境信息
– **TiDB版本**：6.1.0
– **表结构**：test.products表，包含100万行数据
– **索引情况**：有索引
– **操作系统**：Oracle Linux 9.3

## 2. 故障现象
– **SQL执行时间**：正常情况下执行时间为0.1秒，并发时执行时间超过10秒
– **系统负载**：数据库CPU和内存使用率高
– **应用响应**：应用程序在高并发时响应缓慢

## 3. 故障分析
– **SQL语句**：
“`sql
SELECT * FROM test.products WHERE category = ‘electronics’ ORDER BY price DESC LIMIT 100;
“`
– **执行计划**：
“`
+————————-+———+———–+————————+———————————–+-
| id | estRows | task | access object | operator info |
+————————-+———+———–+————————+———————————–+-
| Limit_7 | 100 | root | | limit:100 |
| └─Sort_6 | 100000 | root | | sort:price DESC |
| └─IndexReader_5 | 100000 | root | | index:IndexScan_4 |
| └─IndexScan_4 | 100000 | cop[tikv] | table:products, index:idx_category | range:[“electronics”, “electronics”], keep order:false |
+————————-+———+———–+————————+———————————–+-
“`
– **原因**：高并发时，多个查询同时执行，导致资源竞争，性能下降

## 4. 解决方案
– **步骤1**：优化SQL语句
“`sql
— 添加覆盖索引，减少回表操作
CREATE INDEX idx_category_price ON test.products(category, price DESC);
“`

– **步骤2**：优化执行计划
“`sql
EXPLAIN SELECT * FROM test.products WHERE category = ‘electronics’ ORDER BY price DESC LIMIT 100;
“`
– **执行计划**：
“`
+————————-+———+———–+——————————+———————————–+-
| id | estRows | task | access object | operator info |
+————————-+———+———–+——————————+———————————–+-
| Limit_6 | 100 | root | | limit:100 |
| └─IndexReader_5 | 100 | root | | index:IndexScan_4 |
| └─IndexScan_4 | 100 | cop[tikv] | table:products, index:idx_category_price | range:[“electronics”, “electronics”], keep order:true |
+————————-+———+———–+——————————+———————————–+-
“`

– **步骤3**：配置资源限制
“`toml
# 在tidb.toml中配置
max-concurrent-queries = 2048
stmt-count-limit = 1000000
“`

– **步骤4**：应用程序优化
– 实现查询缓存
– 批量查询
– 异步处理

– **步骤5**：测试并发性能
“`bash
# 使用sysbench测试并发性能
sysbench –db-driver=mysql –mysql-host=192.168.1.10 –mysql-port=4000 –mysql-user=root –mysql-password=password –mysql-db=test –table-size=1000000 –threads=100 –time=60 –report-interval=10 oltp_read_write run
“`

## 5. 预防措施
– **优化索引**：创建覆盖索引，减少回表操作
– **配置资源限制**：合理配置并发参数，避免资源竞争
– **应用程序优化**：实现查询缓存，减少重复查询
– **负载均衡**：使用负载均衡，分散查询压力
– **监控并发性能**：监控并发查询的性能，及时发现问题

## 1. 全表扫描
– **问题**：SQL语句没有使用索引，导致全表扫描
– **解决**：
– 为查询条件添加合适的索引
– 优化SQL语句，确保使用索引
– 分析执行计划，确认索引使用情况

## 2. 索引失效
– **问题**：索引存在但未被使用
– **解决**：
– 避免在索引列上使用函数
– 避免使用不等于操作符
– 避免使用LIKE ‘%xxx’
– 确保查询条件符合索引的最左前缀原则

## 3. 复杂查询
– **问题**：SQL语句包含多个表连接、子查询
– **解决**：
– 简化复杂查询，避免多层嵌套
– 使用连接替代子查询
– 拆分复杂查询为多个简单查询
– 使用物化视图预计算结果

## 4. 大结果集
– **问题**：SQL语句返回大量数据
– **解决**：
– 使用LIMIT限制返回数据量
– 分页查询
– 只查询需要的列
– 使用缓存存储查询结果

## 5. 排序和聚合操作
– **问题**：SQL语句包含大量排序或聚合操作
– **解决**：
– 使用索引排序
– 减少排序和聚合操作
– 增加服务器内存
– 使用列式存储（TiFlash）加速分析查询

## 6. 并发查询
– **问题**：高并发时性能下降
– **解决**：
– 优化索引，减少资源竞争
– 配置合理的并发参数
– 实现查询缓存
– 使用负载均衡，分散查询压力

## 7. 数据倾斜
– **问题**：数据分布不均匀，某些分区数据量过大
– **解决**：
– 合理设计数据分区
– 避免热点数据
– 使用分片技术分散数据
– 定期清理和归档数据

## 8. 统计信息过时
– **问题**：统计信息过时，导致优化器选择错误的执行计划
– **解决**：
– 定期分析表，更新统计信息
– 使用ANALYZE TABLE命令更新统计信息
– 监控统计信息的更新情况