技术博客
PHPWAF 没有“高/中/低”三档按钮式防护等级，它的“强度”由三部分共同决定：php_waf.mode（检测模式）、php_waf.rule_path（加载哪些规则文件）、以及每条规则的 action（是记录、警告还是直接 deny）。很多人误以为改个 mode=strict 就万事大吉，结果发现拦截不准或漏报严重——问题往往出在规则没跟上，或动作没对齐。
普通子查询在 FROM 子句里引用外层表字段会直接报错：ERROR: invalid reference to FROM-clause entry。而 LATERAL 显式声明“这个子查询依赖外层行”，PostgreSQL 就允许它逐行执行、安全展开。关键不是语法糖，是执行模型变了：它把嵌套循环（Nested Loop）的语义写进了 SQL，优化器不再强行尝试提前物化子查询。
只要用户输入进了 query 字符串拼接，就大概率能被绕过。比如用单引号闭合、注释掉后面校验逻辑、或用 UNION SELECT 拖库——这些不是“高级技巧”，而是 SQL 解析器的正常行为。
默认没有硬性行数限制，但有 max_recursive_depth 配置项（仅 PostgreSQL 14+ 支持），且受 statement_timeout 和内存实际消耗制约。多数生产环境卡在 100–1000 层就因超时或 OOM 报错。
JSON_TABLE 是 MySQL 8.0.4+ 提供的函数，核心作用是把一行 JSON 字符串「展开」成多行关系表。它不处理嵌套太深的结构，也不适合做 JSON 校验或提取单个字段——那是 JSON_EXTRACT 或 -> 操作符的事。
数据库调用型后门不直接执行system或eval，而是借合法数据库操作（如mysqli_query、PDO::query）动态拼接并执行恶意SQL，因此常规关键字扫描容易漏掉。
避免全表扫描是MySQL查询优化的关键一步，核心在于让查询能有效利用索引，减少不必要的数据读取。
MySQL 的执行计划（EXPLAIN 输出结果）不是在客户端拼接 SQL 时生成，也不是在存储引擎读数据时才决定，而是在 Server 层的查询优化器（Query Optimizer）完成逻辑解析和语义检查之后、实际执行之前生成的。具体来说，它发生在：parser → resolver → optimizer → executor 这一链条中的 optimizer 阶段。
MySQL 的排序性能优化核心在于减少 filesort，优先利用索引完成排序，避免临时表和磁盘 I/O。关键不是调大 sort_buffer_size，而是让查询“不用排”或“轻量排”。
MySQL 的 JOIN（包括 INNER JOIN、LEFT JOIN 等）**不属于数学意义上的集合运算**（如并集 UNION、交集 INTERSECT、差集 EXCEPT）。它底层先生成笛卡尔积，再用 ON 或 WHERE 做行级筛选——这是**关系代数中的“连接”（Join）操作**，和集合的“并/交/差”有根本区别。