MySQL 查询结果以表格形式返回，需重点关注字段名来源与命名、NULL 值识别、DISTINCT/GROUP BY 对行数的影响、HAVING 与 WHERE 的区别、ORDER BY/LIMIT 的排序分页逻辑，以及多表连接时的字段来源和 JOIN 类型差异。
MySQL 查询执行后，结果以表格形式返回，理解它的结构和含义是数据分析和开发的基础。关键不是“看到什么”，而是“它代表什么”——字段名、行数、空值、排序逻辑、分组聚合效果，都直接影响你对数据的真实判断。
看懂字段名和数据类型
结果第一行是列标题（字段名），它来自 SELECT 后明确指定的字段或表达式。比如 SELECT userid, AMOUNTINFO + 100 FROM sales，第二列标题可能是 AMOUNTINFO + 100（除非用了别名）。注意：
- 若用 *，字段顺序与表定义一致，但不推荐在生产中使用，字段多时易混淆
- 函数或计算列（如 COUNT(*)、GROUP_CONCAT()）会生成新列名，建议用 AS 显式命名，例如 COUNT(*) AS order_count
- NULL 值在结果中显示为空白或 NULL 字样，不是空字符串或 0
识别重复、分组与聚合逻辑
如果你用了 DISTINCT 或 GROUP BY，结果行数通常少于原始表记录数：
- DISTINCT userid：只保留每个 userid 的首次出现，相同值合并为一行
- GROUP BY userid 配合 COUNT(*) 或 SUM(AMOUNTINFO)：每行代表一个 userid 的统计汇总，不是原始明细
- HAVING 是对分组后的结果再过滤，不是对原始行过滤；例如 HAVING COUNT(*) > 1 表示“该用户至少有两条订单”，这一行本身已是对多条记录的压缩
注意排序与分页的实际影响
ORDER BY 和 LIMIT 不改变数据内容，但决定你“看到哪部分”：
- ORDER BY userid DESC, AMOUNTINFO ASC：先按 userid 降序排，userid 相同时才按 AMOUNTINFO 升序；若所有 userid 都不同，AMOUNTINFO 排序实际不生效
- LIMIT 10 只取前 10 行，但没加 ORDER BY 时，顺序不确定——可能每次执行结果不同
- LIMIT 20, 10 表示跳过前 20 行，取接下来的 10 行，常用于分页；但需配合稳定排序（如主键）避免漏数据或重复
多表连接结果要核对来源
连表查询（如 INNER JOIN、LEFT JOIN）的结果列可能来自多个表，字段名容易重叠：
- 务必用表别名区分，例如 e.name AS emp_name, d.name AS dept_name
- INNER JOIN 只保留匹配成功的行；LEFT JOIN 会保留左表全部行，右表无匹配则对应列为 NULL
- 若忘记写 ON 条件，会得到笛卡尔积——行数 = 表 1 行数 × 表 2 行数，数据量暴增且毫无业务意义
