通用：MySQL-InnoDB-count&limit&order优化 - 教程

MySQL-InnoDB实战优化：count/limit/order/group性能瓶颈突破指南

在MySQL-InnoDB环境中，count统计总数、limit分页、order by排序、group by分组是业务开发中最常用的操作，但随着数据量增长（如千万级表），这些操作很容易成为性能瓶颈——比如“统计全表用户数耗时5秒”“分页到第100页时查询超时”“分组排序后接口响应延迟”。

很多开发者会简单认为“加索引就行”，但实际情况往往更复杂：InnoDB的事务特性（MVCC）会影响count效率，limit的“偏移量过大”问题无法靠单一索引解决，order by与group by的组合可能触发临时表与文件排序。

一、InnoDB-count优化：为什么统计总数这么慢？

count(*)是业务中高频需求（如“显示用户总数”“统计订单量”），但在InnoDB中，它的效率远低于MyISAM——因为两者的存储引擎特性完全不同。

1.1 先搞懂：InnoDB与MyISAM的count差异

MyISAM：在表结构文件（.MYI）中维护了一个“总行数计数器”，执行count(*)时直接读取该计数器，耗时O(1)；但该计数器不支持WHERE条件（如count(*) where status=1仍需全表扫描），且不支持事务（并发写时计数器可能不准）。
InnoDB：没有全局总行数计数器，执行count(*)时必须“逐行统计”——因为InnoDB支持MVCC（多版本并发控制），不同事务看到的“总行数”可能不同（比如事务A插入的行，事务B未提交前看不到），只能通过扫描数据或索引来计算行数。

这就导致：当表数据量超过100万行时，InnoDB的count(*)很容易耗时过久（如千万级表统计全表行数需3-10秒）。

1.2 工作中常见的count场景与优化方案

根据是否带WHERE条件，count可分为“全表统计”和“条件统计”，优化方案需针对性设计。

场景1：全表count(*)（如“用户总数”“商品总数”）

痛点：全表扫描或全索引扫描，数据量越大越慢。
优化方案（按优先级排序）：

利用“覆盖索引”减少扫描成本
InnoDB扫描索引比扫描全表快（索引文件远小于数据文件），且count(*)不需要读取数据行，只需统计索引行数。
- 操作：给表加一个“单列非空索引”（如idx_id，利用主键索引更优，因为主键索引是聚簇索引，数据与索引同文件，但主键索引体积可能更大，建议用非空的普通索引）。
- 原理：执行count(*)时，MySQL会自动选择最小的索引（通过EXPLAIN可看到key字段为该索引），扫描索引树统计行数，比全表扫描快5-10倍。
- 示例：
```
-- 给users表加非空索引（若已有主键，可直接用主键索引）
ALTER TABLE users ADD INDEX idx_non_null (user_name); -- 确保user_name非空
-- 执行count(*)，会走idx_non_null索引
SELECT count(*) FROM users;
```
缓存结果（适合非实时统计场景）
若业务允许“统计结果有1-5分钟延迟”（如后台管理系统的用户总数），可将count(*)结果缓存到Redis，定期更新。
- 方案：
  - 定时任务：每5分钟执行count(*)，将结果存入Redis（如SET user_total 123456）；
  - 增量更新：若有插入/删除操作，同步更新Redis（如插入时INCR user_total，删除时DECR user_total），避免定时任务的“统计偏差”。
- 注意：需处理缓存穿透（如Redis键过期时，避免大量请求直接查DB），可加临时缓存或互斥锁。

分区表（千万级以上表）
若表数据量超过5000万行，可将表按“时间”或“地区”分区（如orders表按create_time分12个月度分区），执行count(*)时只需扫描所有分区的索引，比单表全索引扫描快（分区表可并行扫描）。

示例：

-- 创建按时间分区的orders表
CREATE TABLE orders (
order_id INT PRIMARY KEY,
create_time DATETIME
)
PARTITION BY RANGE (TO_DAYS(create_time)) (
PARTITION p202401 VALUES LESS THAN (TO_DAYS('2024-02-01')),
PARTITION p202402 VALUES LESS THAN (TO_DAYS('2024-03-01')),
...
);
-- 统计全表行数，会并行扫描所有分区
SELECT count(*) FROM orders;

场景2：带WHERE条件的count（如“已支付订单数”“近7天新增用户数”）

痛点：若WHERE条件无合适索引，会触发全表扫描；若条件过滤性差（如“统计近1年订单数”），即使有索引也需扫描大量数据。
优化方案：

给WHERE条件加“过滤性强的索引”
核心是让count通过索引快速过滤数据，减少扫描行数。

原则：索引字段需覆盖WHERE条件，且索引选择性高（过滤后的数据量占比低，如“status=2”只占总订单的10%）。

示例：

-- 需求：统计status=2（已支付）的订单数
-- 优化前：无索引，全表扫描
SELECT count(*) FROM orders WHERE status=2; -- 千万级表耗时5秒
-- 优化后：给status加索引
ALTER TABLE orders ADD INDEX idx_status (status);
SELECT count(*) FROM orders WHERE status=2; -- 耗时降至50ms

联合索引覆盖多条件
若WHERE条件有多个字段（如“status=2且create_time>=‘2024-01-01’”），需创建联合索引，让索引同时覆盖多个条件，避免“回表过滤”。

示例：

-- 需求：统计2024年以来已支付的订单数
-- 优化：创建联合索引（status在前，create_time在后，因status过滤性更强）
ALTER TABLE orders ADD INDEX idx_status_time (status, create_time);
-- 执行count，走联合索引，无需回表
SELECT count(*) FROM orders WHERE status=2 AND create_time >= '2024-01-01';

此处需要注意的是，如果联合索引创建的是(create_time,status)，则会导致索引部分失效：只能用到status的索引，无法用到create_time的索引。因为create_time用了范围查询，会导致status的索引失败。

预计算（实时性要求高的场景）
若业务需要“实时统计”（如电商首页的“实时销量”），可通过“预计算表”存储统计结果，避免实时count。
- 方案：
  - 创建预计算表：order_stat(status INT PRIMARY KEY, total INT)，存储不同状态的订单数；
  - 触发器/业务层更新：当orders表插入/更新/删除时，同步更新order_stat（如插入status=2的订单时，UPDATE order_stat SET total=total+1 WHERE status=2）；
  - 查询时直接读预计算表：SELECT total FROM order_stat WHERE status=2，耗时O(1)。

1.3 避坑：count(*)、count(1)、count(字段)的区别

很多开发者纠结“哪种count更快”，实际差异主要在InnoDB中：

count(*)：InnoDB会忽略所有字段，直接统计行数（优先走最小索引），效率最高；
count(1)：与count()逻辑类似，InnoDB会给每行加一个“虚拟值1”，统计1的个数，效率与count()几乎无差异（MySQL 5.7+已优化）；
count(字段)：需判断字段是否为NULL，非NULL才统计，效率最低（若字段无索引，需全表扫描；若有索引，需扫描索引并判断NULL）。

结论：工作中优先用count(*)，无需纠结count(1)，避免用count(字段)（除非需统计非NULL字段数）。

二、InnoDB-limit优化：分页到第100页时为什么会超时？

limit offset, size是分页查询的标准写法（如limit 1000, 20表示取第51页，每页20条），但在InnoDB中，当offset（偏移量）过大时，性能会急剧下降——比如limit 100000, 20，MySQL会先扫描前100020条数据，再丢弃前100000条，只返回20条，严重浪费资源。

2.1 痛点拆解：offset过大的性能问题

以“订单分页查询”为例，SQL如下：

-- 分页查询第5001页（offset=100000，size=20）
SELECT order_id, user_id, create_time
FROM orders
ORDER BY create_time DESC
LIMIT 100000, 20;

执行过程：
1. 按create_time DESC排序（若有索引，走索引排序；若无，走文件排序）；
2. 扫描前100020条数据；
3. 丢弃前100000条，返回后20条。
问题：offset越大，扫描的数据越多，耗时越长（千万级表中，limit 100000,20可能耗时2-3秒）。

2.2 工作中常用的limit优化方案

方案1：用“主键/唯一索引”做偏移量（适合主键连续的场景）

核心思路：避免用offset，改用“主键范围查询”，直接定位到起始位置，减少扫描行数。

原理：InnoDB的主键是聚簇索引，按主键查询时可快速定位到数据行，无需扫描前面的偏移量数据。

示例：

-- 优化前：offset=100000，扫描100020条
SELECT order_id, user_id, create_time
FROM orders
ORDER BY order_id DESC
LIMIT 100000, 20;
-- 优化后：记录上一页的最大主键（如last_order_id=100000），用主键范围查询
SELECT order_id, user_id, create_time
FROM orders
WHERE order_id < 100000 -- 上一页最大order_id
ORDER BY order_id DESC
LIMIT 20; -- 直接取20条

优势：扫描行数从100020降至20，耗时从秒级降至毫秒级；
限制：需满足“主键连续”（或按主键排序），且前端需记录“上一页的最后一个主键”（如分页控件中传递last_id）。

方案2：联合索引覆盖分页字段（适合非主键排序场景）

若分页需按“非主键字段”排序（如按create_time DESC分页），可创建“联合索引”覆盖“排序字段+主键”，让MySQL通过索引快速定位到起始位置，避免全表排序。

原理：联合索引按“排序字段+主键”有序存储，MySQL可通过索引直接找到“offset对应的排序位置”，再通过主键回表查询数据（若索引覆盖查询字段，可避免回表）。

示例：

-- 需求：按create_time DESC分页，查询order_id、user_id、create_time
-- 优化1：创建联合索引（create_time DESC, order_id DESC）
ALTER TABLE orders ADD INDEX idx_time_id (create_time DESC, order_id DESC);
-- 优化前：offset=100000，需扫描100020条并排序
SELECT order_id, user_id, create_time
FROM orders
ORDER BY create_time DESC
LIMIT 100000, 20; -- 耗时2秒
-- 优化后：记录上一页的最后一个create_time和order_id（如last_time='2024-05-01 12:00:00'，last_id=100000）
SELECT order_id, user_id, create_time
FROM orders
WHERE create_time < '2024-05-01 12:00:00' -- 上一页最后时间
OR (create_time = '2024-05-01 12:00:00' AND order_id < 100000) -- 时间相同则按主键过滤
ORDER BY create_time DESC, order_id DESC
LIMIT 20; -- 耗时10ms

关键：需处理“排序字段值相同”的情况（如多个订单的create_time相同），此时需用主键二次过滤，避免漏数据；
覆盖索引优化：若查询字段（order_id、user_id、create_time）都在联合索引中，可将索引改为idx_time_id_user (create_time DESC, order_id DESC, user_id)，实现“覆盖索引查询”，无需回表，进一步提升效率。

方案3：限制最大分页页数（业务层面优化）

很多业务场景中，用户很少会翻到第100页以后（如电商商品列表，用户通常只看前10页），可在业务层限制“最大分页页数”（如最多支持100页），超过则提示“无更多数据”，避免offset过大的查询。

示例：

-- 业务层判断：若offset >= 2000（100页*20条），直接返回空
if (offset >= 2000) {
return empty;
} else {
execute "SELECT ... LIMIT #{offset}, #{size}";
}

方案4：用子查询定位起始主键（兼容旧系统）

若前端无法修改分页参数（如只能传递pageNum和pageSize），可通过“子查询”先找到offset对应的主键，再用主键范围查询，减少扫描行数。

示例：

-- 需求：分页第5001页（pageNum=5001，pageSize=20，offset=100000）
-- 步骤1：子查询找到第100001条数据的主键（order_id）
-- 步骤2：用主键范围查询取后面20条
SELECT o.order_id, o.user_id, o.create_time
FROM orders o
JOIN (
-- 子查询走idx_time_id索引，快速找到offset对应的order_id
SELECT order_id
FROM orders
ORDER BY create_time DESC
LIMIT 100000, 1 -- 取第100001条的order_id
) AS t ON o.order_id = t.order_id
ORDER BY o.create_time DESC
LIMIT 20;

优势：子查询只需扫描100001条索引数据（比全表扫描快），主查询通过主键定位20条数据，总耗时比直接limit 100000,20快5-10倍。

三、InnoDB-order by优化：如何避免“文件排序”？

order by是排序操作的核心，但在InnoDB中，若排序字段无合适索引，会触发Using filesort（文件排序）——MySQL将数据读取到内存/磁盘中，通过排序算法（如快速排序）排序，耗时极高（千万级表排序可能耗时10秒以上）。

1.先理解：InnoDB的两种排序方式

InnoDB执行order by时，有两种排序策略，效率差异巨大：

索引排序（Using index）：排序字段在索引中，MySQL直接按索引顺序读取数据，无需额外排序，效率极高（O(n)）；
文件排序（Using filesort）：排序字段无索引，MySQL需先读取数据到“排序缓冲区”（sort_buffer_size），若数据量超过缓冲区，需写入临时文件（磁盘IO），再用排序算法排序，效率极低

索引顺序不对、查询字段未覆盖、排序方向不匹配等，都会让索引失效，进而触发文件排序。

先懂原理：InnoDB 的两种排序方式
InnoDB 执行 order by 时，会根据“是否有合适索引”选择两种完全不同的排序策略，两者性能差异悬殊，这是优化的核心依据。

索引排序（Using index）：高效排序
当排序字段与索引字段完全匹配时，InnoDB 会直接按索引顺序读取数据，无需额外排序操作，这是最优的排序方式。

原理：索引的“有序性”特性
InnoDB 的 B+ 树索引本身是“有序存储”的（如 idx_create_time 索引按 create_time 升序排列），叶子节点存储了数据行的位置（聚簇索引则存储完整数据）。执行 order by create_time 时，InnoDB 只需从索引树的叶子节点“顺序遍历”，即可获取有序数据，无需额外排序。

关键特征：

EXPLAIN 结果中 Extra 字段显示 Using index（若索引覆盖查询字段）或 Using where; Using index（若需过滤条件）；
排序耗时与数据量呈线性增长（O(n)），千万级数据也能快速排序；
无额外内存/磁盘开销（无需创建排序缓冲区或临时文件）。

文件排序（Using filesort）：低效排序
当排序字段无合适索引时，InnoDB 会先将数据读取到“排序缓冲区”，再通过排序算法（如快速排序）排序，若数据量超过缓冲区，则需写入临时文件（磁盘 IO），这就是文件排序。

执行流程：

读取数据：从表中读取满足 WHERE 条件的所有数据行（全表扫描或索引扫描后回表）；
写入排序缓冲区：将“排序字段+数据行指针”存入 sort_buffer_size 配置的缓冲区；
排序：若缓冲区已满，先对缓冲区数据排序并写入临时文件；
合并排序结果：所有数据读取完成后，合并临时文件中的排序结果；
返回数据：按排序结果读取数据行并返回。

关键特征：

EXPLAIN 结果中 Extra 字段显示 Using filesort；
排序耗时与数据量呈指数增长（O(n log n)），百万级数据可能耗时数秒；
依赖磁盘 IO（临时文件），IO 密集场景下性能会急剧下降。

2.核心痛点：哪些情况会触发文件排序？

工作中，很多看似“合理”的 order by 语句会触发文件排序，核心原因可归纳为以下4类：

1.排序字段无索引

这是最直接的原因：若 order by 后的字段未建索引，必然触发文件排序。

示例：

-- orders 表未给 create_time 建索引
SELECT order_id, create_time FROM orders
ORDER BY create_time DESC; -- 触发 Using filesort

2.索引顺序与排序顺序不匹配（联合索引场景）

联合索引的“最左前缀原则”不仅适用于 WHERE 条件，也适用于 order by —— 若排序字段未遵循索引的“左到右”顺序，索引会失效。

示例：

-- 建联合索引 idx_user_time (user_id, create_time)
-- 情况1：排序字段包含索引未覆盖的字段，触发文件排序
SELECT order_id, user_id, create_time FROM orders
ORDER BY user_id DESC, pay_time DESC; -- pay_time 不在索引中，触发 filesort
-- 情况2：跳过索引左侧字段，直接排序右侧字段，触发文件排序
SELECT order_id, user_id, create_time FROM orders
ORDER BY create_time DESC; -- 跳过 user_id，索引失效，触发 filesort

3.排序方向与索引方向不匹配

InnoDB 的索引默认按“升序（ASC）”存储，若 order by 用“降序（DESC）”，且索引未显式指定 DESC，会导致索引无法复用，触发文件排序（MySQL 8.0+ 已优化部分场景，但仍需注意）。

示例：

-- 建索引时未指定方向（默认 ASC）
CREATE INDEX idx_create_time ON orders (create_time);
-- 排序方向为 DESC，与索引方向不匹配（MySQL 5.7 及以下触发 filesort）
SELECT order_id, create_time FROM orders
ORDER BY create_time DESC; -- 触发 Using filesort

4.WHERE 条件与排序字段的索引未覆盖

即使排序字段有索引，但如果查询的“非排序字段”未在索引中（需回表查询），且数据量较大时，MySQL 可能会放弃索引排序，选择文件排序（认为“回表成本高于排序成本”）。

示例：

-- 给 create_time 建单列索引 idx_create_time
-- 查询字段包含非索引字段 user_id（需回表）
SELECT order_id, user_id, create_time FROM orders
ORDER BY create_time DESC; -- 若数据量较大，触发 Using filesort

3.实战优化：如何避免文件排序？

针对上述痛点，结合 InnoDB 索引特性，给出4套核心优化方案，覆盖90%以上的业务场景：

方案1：给排序字段建“单列索引”（单字段排序场景）

若 order by 仅涉及单个字段，直接给该字段建单列索引，即可避免文件排序。

优化步骤：

确认排序字段，创建索引（显式指定排序方向，适配 order by 需求）；
用 EXPLAIN 验证索引是否生效（Extra 无 Using filesort）。

示例：

-- 需求：按 create_time DESC 排序
-- 优化1：建索引时显式指定 DESC，适配排序方向
CREATE INDEX idx_create_time_desc ON orders (create_time DESC);
-- 优化后查询，无 Using filesort
SELECT order_id, create_time FROM orders
ORDER BY create_time DESC; -- EXPLAIN 显示 Using index

注意：MySQL 8.0+ 支持“混合排序方向”（如 order by a ASC, b DESC），但需索引显式匹配方向（如 idx_a_b (a ASC, b DESC)），否则仍会触发文件排序。

方案2：建“联合索引”覆盖 WHERE + ORDER BY（多条件场景）

若查询同时包含 WHERE 条件和 order by，需创建“WHERE 条件字段 + 排序字段”的联合索引，确保两者都能复用索引。

核心原则：

联合索引的“左侧”放 WHERE 条件中的过滤字段（选择性高的字段优先）；
联合索引的“右侧”放 order by 中的排序字段；
索引方向需与 order by 方向一致。

示例：

-- 需求：查询 user_id=100 的订单，按 create_time DESC 排序
-- 优化前：单字段索引无法覆盖 WHERE + ORDER BY，触发 filesort
CREATE INDEX idx_user_id ON orders (user_id);
SELECT order_id, user_id, create_time FROM orders
WHERE user_id = 100
ORDER BY create_time DESC; -- 触发 Using filesort
-- 优化后：建联合索引覆盖 WHERE + ORDER BY
CREATE INDEX idx_user_time_desc ON orders (user_id, create_time DESC);
SELECT order_id, user_id, create_time FROM orders
WHERE user_id = 100
ORDER BY create_time DESC; -- EXPLAIN 显示 Using index，无 filesort

方案3：建“覆盖索引”避免回表（非排序字段查询场景）

若查询需返回“非排序字段”（如 user_id），且该字段不在索引中，会导致回表，进而触发文件排序。此时需将“非排序字段”加入索引，创建“覆盖索引”，避免回表。

示例：

-- 需求：查询 order_id、user_id、create_time，按 create_time DESC 排序
-- 优化前：单列索引仅覆盖 create_time，需回表查 user_id，触发 filesort
CREATE INDEX idx_create_time_desc ON orders (create_time DESC);
SELECT order_id, user_id, create_time FROM orders
ORDER BY create_time DESC; -- 触发 Using filesort
-- 优化后：建覆盖索引，包含所有查询字段
CREATE INDEX idx_time_user_order ON orders (create_time DESC, user_id, order_id);
SELECT order_id, user_id, create_time FROM orders
ORDER BY create_time DESC; -- EXPLAIN 显示 Using index，无 filesort

关键：覆盖索引的字段顺序不影响“排序”，但需包含所有查询字段（避免回表），字段顺序建议按“排序字段在前，查询字段在后”排列（减少索引体积）。

方案4：控制排序数据量（大数据量场景）

若业务需排序的数据量极大（如千万级），即使有索引，排序耗时也可能较高，此时需从“业务层面”控制数据量：

（1）先过滤再排序

通过 WHERE 条件先筛选出“小范围数据”，再对小范围数据排序，减少排序的数据量。

示例：

-- 优化前：对全表数据排序，数据量过大
SELECT order_id, create_time FROM orders
ORDER BY create_time DESC; -- 排序千万级数据
-- 优化后：先过滤近30天数据，再排序（数据量减少90%）
SELECT order_id, create_time FROM orders
WHERE create_time >= DATE_SUB(NOW(), INTERVAL 30 DAY)
ORDER BY create_time DESC; -- 仅排序30天内数据

（2）分页限制最大条数

用户很少会翻到第100页以后，可限制 order by 结合 limit 的最大偏移量（如最大支持 10000 条），避免对超大量数据排序。

示例：

-- 限制最大偏移量为 10000，超过则提示“无更多数据”
SELECT order_id, create_time FROM orders
ORDER BY create_time DESC
LIMIT 10000, 20; -- 偏移量超过 10000 时，返回空

四、进阶优化：MySQL 8.0+ 新特性助力排序

MySQL 8.0 引入了两项对 order by 友好的新特性，可进一步提升排序性能：

4.1 降序索引（Descending Indexes）

MySQL 5.7 及以下版本，联合索引中若有字段用 DESC，整个索引仍按 ASC 存储，仅在查询时反向读取；MySQL 8.0 支持“真正的降序索引”，索引按 DESC 顺序存储，order by DESC 时可直接复用索引，无需反向读取。

示例：

-- MySQL 8.0 支持联合索引中混合 ASC/DESC
CREATE INDEX idx_user_time_mix ON orders (user_id ASC, create_time DESC);
-- 排序方向与索引完全匹配，无 filesort
SELECT order_id, user_id, create_time FROM orders
ORDER BY user_id ASC, create_time DESC; -- 索引生效

4.2 隐藏索引（Invisible Indexes）

优化 order by 索引时，若担心“删除旧索引影响业务”，可先将旧索引设为“隐藏索引”，验证新索引生效后再删除旧索引，降低优化风险。

示例：

-- 将旧索引设为隐藏（不影响查询，但优化器不会使用）
ALTER TABLE orders ALTER INDEX idx_old_create_time INVISIBLE;
-- 验证新索引是否生效（EXPLAIN 显示新索引）
SELECT order_id, create_time FROM orders
ORDER BY create_time DESC;
-- 确认无问题后，删除旧索引
DROP INDEX idx_old_create_time ON orders;

五、实战案例：从“文件排序”到“索引排序”的优化全过程

以电商“订单列表排序”为例，完整演示优化步骤：

5.1 原始需求与问题

需求：查询用户 ID=100 的订单，按创建时间降序显示，返回订单 ID、创建时间、支付金额。
原始 SQL：

SELECT order_id, create_time, pay_amount FROM orders
WHERE user_id = 100
ORDER BY create_time DESC;

问题：EXPLAIN 显示 type=ALL，Extra=Using where; Using filesort，百万级数据耗时 3.5 秒。

5.2 优化步骤

分析痛点：user_id 无索引（WHERE 条件全表扫描），create_time 无索引（order by 触发文件排序），查询字段 pay_amount 需回表。
建覆盖联合索引：
- 索引字段：user_id（WHERE 条件）、create_time DESC（排序）、pay_amount（查询字段）、order_id（查询字段）；
- 索引名称：idx_user_time_pay。
```
CREATE INDEX idx_user_time_pay ON orders (user_id, create_time DESC, pay_amount, order_id);
```
验证优化结果：
- EXPLAIN 显示 type=ref，key=idx_user_time_pay，Extra=Using index；
- 执行耗时从 3.5 秒降至 0.02 秒，性能提升 175 倍。

六、总结：order by 优化的核心原则

索引优先：order by 必须建索引，单字段排序用“单列索引”，多条件排序用“联合索引”；
顺序匹配：联合索引需遵循“WHERE 字段在前，排序字段在后”，排序方向与索引方向一致；
覆盖为王：索引需包含所有查询字段（避免回表），减少优化器放弃索引的概率；
控制数据量：先过滤再排序，限制最大分页条数，避免对超大量数据排序；
版本利用：MySQL 8.0+ 优先用“降序索引”“隐藏索引”，提升优化效率与安全性。

Studying will never be ending.

▲如有纰漏，烦请指正~~

posted on 2025-11-07 08:26 mthoutai 阅读(24) 评论(0) 收藏举报

刷新页面返回顶部