一、影响因素
查询一个包含1亿条数据的表，并使用 LIMIT 99999990, 10 来获取最后的10条记录，性能慢的原因主要是因为 LIMIT 子句的偏移量（offset）非常大。以下是一些导致性能问题的关键因素
- 大量跳过 - LIMIT 子句的前一个数字（99999990）是告诉数据库跳过前99999990条记录，这需要数据库扫描并跳过这些记录才能返回最后的10条。
- 全表扫描 - 如果没有有效的索引来支持这种类型的查询，数据库可能需要执行全表扫描，这在数据量大的情况下非常耗时。
- 排序开销 - 如果查询中包含 ORDER BY 子句，并且排序的列没有索引，数据库需要对所有记录进行排序，这会增加大量的CPU和内存开销。
- 临时表空间 - 排序操作可能需要使用临时表空间，对于大量数据，这可能会消耗大量的磁盘I/O资源。
- 锁定和闩锁 - 大量的跳过和扫描可能导致数据库锁定和闩锁，影响并发性能，甚至导致其他查询和更新操作被阻塞。
- 资源耗尽 - 如果数据库服务器的硬件资源（如CPU、内存、I/O）有限，这种类型的查询可能会消耗大量资源，导致服务器响应缓慢或宕机。
二、优化措施
为了避免这些问题，可以采取以下优化措施- 使用索引 - 确保有一个索引可以快速定位到接近表末尾的位置。例如，如果有一个时间戳或自增ID列，可以在这个列上创建索引。
- 优化查询 - 如果可能，重写查询逻辑，避免使用大偏移量。如果需要获取最后10条记录，考虑使用其他逻辑来确定这10条记录的位置。
- 分批处理 - 如果需要处理大量数据，考虑使用分批查询和处理的方法，每次处理一小部分数据。
- 资源优化 - 根据服务器的硬件配置优化数据库的配置，如增加内存分配，优化I/O性能等。
- 分布式查询 - 对于非常大的表，考虑使用分区表或分布式数据库系统，以提高查询性能。
- 监控和调优 - 使用数据库的性能监控工具来识别瓶颈，并根据需要进行调优。
- 避免大偏移量 - 如果业务逻辑允许，避免使用带有大偏移量的 LIMIT 子句，因为这通常是一个性能杀手。
在某些情况下，如果表的结构和数据分布允许，可以通过其他方法来获取最后几条记录，例如，如果有一个自增ID，可以先获取最大ID，然后查询紧随其后的记录。
