split是最轻量可控的大日志切割手段，支持按行（-l）或按字节（-b）分割，不修改原文件、不影响服务，切后可用head/grep快速定位问题段。
别硬开，大日志文件用 vim 或 less 打开大概率卡死甚至 OOM，直接切或流式查才是正解。
用 split 切割超大日志文件再逐段分析
当 /var/log/mysql/error.log 或 slow-query.log 达到几十 GB，vim 会尝试加载全部内容进内存，极易拖垮服务器。此时 split 是最轻量、最可控的切割手段。
-
split -l 100000 /var/log/mysql/error.log error_part_：按行数切，每份 10 万行，生成error_part_aa、error_part_ab等 -
split -b 500M /var/log/mysql/slow.log slow_part_：按字节切，每份 500MB，适合二进制安全场景（如含非 UTF-8 字符） - 切完立刻用
head -n 20 error_part_aa或grep "ERROR" error_part_ab快速定位问题段，不用等加载 - 注意：
split不修改原文件，也不影响 MySQL 写入，纯读操作，零风险
用 tail/head + grep 流式排查关键信息
绝大多数排查需求其实只关心“最近出错”或“某类错误高频出现”，根本不需要全文打开。
-
tail -n 50000 /var/log/mysql/error.log | grep -i "connection.*refused\|crash\|OOM"：查末尾 5 万行里的典型错误关键词 -
head -n 1000000 /var/log/mysql/slow.log | awk '{print $2}' | sort | uniq -c | sort -nr | head -10：快速统计前 100 万行中耗时最长的 SQL 出现频次 - 加
-f可实时跟踪：tail -f /var/log/mysql/error.log | grep --line-buffered "Aborted connection"，配合--line-buffered避免输出延迟 - 避免用
cat big.log | grep ...——会先读完整个文件，失去流式优势
为什么不用 less 或 vim 直接看？
不是它们不行，而是默认行为对大日志极不友好：
-
less启动时仍会尝试扫描文件结构（比如计算总行数），遇到 TB 级日志可能卡住几分钟没响应 -
vim默认启用语法高亮和行号，会触发全文件解析，内存占用飙升；即使加vim -u NONE -U NONE +set\ nobin也难保稳定 - 两者都无法跳过中间无用段落——你只想看崩溃前 10 分钟，但它们强迫你从头索引
- 真正安全的替代是
less +G（直接跳末尾）或less +/pattern（正则跳转），但前提是文件已建立索引（大日志首次打开仍慢）
真正麻烦的从来不是“怎么打开”，而是“怎么确认该看哪一段”。切分和流式过滤不是权宜之计，是面对百 GB 日志时唯一可依赖的起点——先锚定时间窗口或错误模式，再决定是否需要进一步切片或导出。
