SQL注入的网站利用方式，在50条和50条以下，注入完全是上和什区两码事。很多人以为只是网站数字大小的问题，实际操作起来，注入差别大到能决定你这次渗透是上和什区拿下一个后台，还是网站只能看到一行报错。

先说说50条以下的注入情况。假设你发现一个注入点，上和什区用 order by 测出字段数是网站3，然后 union select 1,注入2,3 回显正常。这时候你想读数据，上和什区通常就是网站 union select 1,user(),database() 这种套路。一次只能带出一行，注入或者用 group_concat 把多行拼成一条。上和什区但 group_concat 有长度限制，默认1024字节，超了就被截断。你读 information_schema.tables 的时候，如果表多，一次根本读不完。得配合 limit 一页一页翻。50条以下，你翻个几十页还能忍，手工注入或者sqlmap跑起来都还算顺畅。

但一旦数据量超过50条，尤其是你要拖 users 表里的账号密码，或者 orders 表里的交易记录，情况就变了。我遇到过一个大站，注入点回显位只有两个，group_concat 被WAF拦了，只能 limit 0,1 一条一条读。表里有六万多条记录，按这个速度，读到明年也读不完。这时候就得换思路，不能硬拖。

50条以上，第一个要面对的是分页效率。MySQL的 limit 在偏移量大的时候性能急剧下降。limit 100000,10 和 limit 0,10 完全不是一个量级。注入的时候你没法控制索引，只能硬扫。如果目标表有几十万行，你读第500页的时候，数据库可能直接超时，或者把连接池占满，导致整个站挂掉。这不是理论，我亲眼见过一个兄弟用sqlmap的 --threads=10 跑一个偏移量很大的注入点，直接把对方MySQL的CPU干到100%，然后网站502了。

第二个区别是WAF和审计日志的触发概率。50条以下，你慢慢读，请求间隔拉长，流量特征不明显。50条以上，尤其是你要批量导出，请求频率一高，WAF的规则就命中了。很多云WAF对 union select 后面跟大数字、或者 limit 偏移量超过某个阈值，会直接拦截。我试过某厂商的WAF，limit 0,50 放行，limit 50,50 就弹验证码。你说气不气？

第三个区别在数据聚合方式上。50条以下，你还能用 concat 把多个字段拼一起，或者用 group_concat 碰运气。50条以上，必须考虑用 into outfile 写文件，或者用 load_file 读文件，再或者用DNS外带。因为 union 查询的回显位就那么宽，你塞不下那么多数据。我常用的手法是，如果 secure_file_priv 为空，直接 union select 1,concat(0x7e,(select group_concat(table_name) from information_schema.tables where table_schema=database()),0x7e),3，但表一多就爆。这时候就得写脚本，用 limit 循环，每50条一批，写到本地文件里。

还有一个坑，50条以上容易触发MySQL的 max_allowed_packet 限制。你 group_concat 拼一个超长字符串，超过这个值直接报错，注入点就废了。50条以下基本不会碰到这个。

实际案例：去年我测一个电商站，注入点回显位两个。用户表有12万条。我先用 group_concat 试，只出来前30个用户名，后面全被截断。换 limit 分页，每页50条，读到第200页的时候，WAF开始返回403。最后我是用 order by 配合二分法，先定位到管理员账号所在的ID区间，只读了那附近的20条，才拿到密码。如果硬读12万条，不仅慢，而且必然被封。

所以，50条以下，你是在“读数据”；50条以上，你是在“偷数据”。前者靠技巧，后者靠策略。别小看这个数字，它决定了你是用sqlmap一键梭哈，还是得手写Python脚本、控制速率、绕WAF、分批次落地。搞注入，心里得有一本账，数据量一过50，就得换打法。