DatetimeIndex必须单调递增才能加速切片，因.loc和.truncate()在单调索引上启用二分查找（O(log n)），乱序则退化为全量扫描（O(n)）；常见现象是切片响应慢、CPU飙升，可用.is_monotonic_increasing检查，需sort_index并去重验证。
为什么DatetimeIndex必须单调递增才能加速切片？
因为Pandas的.loc和.truncate()在单调索引上会自动启用二分查找（bisect），时间复杂度从O(n)降到O(log n)；如果索引乱序，Pandas只能退化为全量扫描——哪怕你只查1秒的数据，也要遍历整个DataFrame。
常见错误现象：df.loc['2023-01-01':'2023-01-02']响应慢、CPU飙升、甚至卡死；用df.index.is_monotonic_increasing检查返回False就是铁证。
- 强制排序：用
df.sort_index(inplace=True)，别依赖原始数据顺序 - 避免重复时间戳：
df = df[~df.index.duplicated(keep='first')]，否则.loc行为不可控 - 排序后务必验证：
assert df.index.is_monotonic_increasing，CI里加这行能早发现问题
pd.to_datetime()解析慢？换format参数+cache=True
海量时序数据中，字符串转DatetimeIndex常是性能瓶颈。默认的infer_datetime_format=False会让Pandas逐个尝试多种格式，开销极大。
使用场景：CSV/Parquet里时间列是'2023-01-01 12:34:56.789'这类固定格式字符串。
立即学习“Python免费学习笔记（深入）”；
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 明确指定格式：
pd.to_datetime(df['ts'], format='%Y-%m-%d %H:%M:%S.%f', cache=True) -
cache=True对重复字符串（如每条记录都带相同日期）有显著加速，实测提升3–5倍 - 避免用
unit='ns'直接传整数时间戳——除非原始数据本身就是纳秒整数，否则易溢出或错位
切片查询别只靠.loc，试试.truncate()和query()
.truncate()专为有序索引设计，语义清晰且内部跳过校验逻辑，比.loc轻量；而.query()在混合条件（如时间+数值过滤）时更直观，且支持numexpr加速。
性能差异示例：对1亿行数据查1小时窗口，.truncate(before='2023-01-01', after='2023-01-01 01:00')比等效.loc快15–20%。
- 纯时间范围切片优先用
.truncate()，它不接受布尔表达式，但更稳更快 - 需要同时过滤字段（如
value > 100）时，用df.query("index >= '2023-01-01' and index 100") - 禁用
.ix——已弃用，且在混合索引下行为诡异
内存映射+分区读取比“全量加载+索引”更实际
当数据大到放不进内存（比如单文件超20GB），光优化索引没用——Python进程先被OOM kill了。这时候得绕过“全量建索引”这个前提。
真实可行路径：用pyarrow或fastparquet按时间分区存储（如/data/year=2023/month=01/day=01/），查询时只读目标分区。
- Parquet文件天然支持
filters下推：pd.read_parquet('data/', filters=[('year', '==', 2023), ('month', '==', 1)]) - 用
datetime列做分区键，别用字符串；否则filters无法利用统计信息跳过文件 - 分区后仍需在每个分区内确保
DatetimeIndex单调——分区只是减量，不是免索引
最易被忽略的一点：pd.to_datetime()默认errors='raise'，遇到脏数据直接中断；生产环境必须设errors='coerce'并后续清洗，否则分区读取可能静默失败。
