SQL全列模糊查询快捷方式、性能对比及过滤性能技术问询

1. 原SQL逻辑修正与全列模糊匹配实现 #

首先你的原SQL存在逻辑错误：AND的优先级高于OR，实际执行逻辑是(status = 'Finished' AND aukcja LIKE '%tshirt%') OR name LIKE '%tshirt%' OR comment LIKE '%tshirt%'，这会把status不是Finished但name或comment含tshirt的数据也查出来，不符合需求。正确写法需把三个LIKE条件用括号包裹：

SELECT * 
FROM orders 
WHERE status = 'Finished' 
  AND (aukcja LIKE '%tshirt%' OR name LIKE '%tshirt%' OR comment LIKE '%tshirt%')

关于全列（排除非字符串列）模糊匹配，SQL标准没有COLUMN INCLUDE '%tshirt%'这类直接语法，但可以通过动态SQL结合系统表实现：

• 先从系统表中筛选orders表的字符串类型列（排除日期、ID等非字符串列）
• 动态拼接OR column LIKE '%tshirt%'的条件

以MySQL为例，动态SQL示例：

SET @sql = NULL;
SELECT CONCAT(
  'SELECT * FROM orders WHERE status = ''Finished'' AND (',
  GROUP_CONCAT(COLUMN_NAME, ' LIKE ''%tshirt%'' SEPARATOR '' OR '' '),
  ')'
) INTO @sql
FROM information_schema.columns
WHERE table_schema = '你的数据库名'
  AND table_name = 'orders'
  AND data_type IN ('varchar', 'text', 'char'); -- 根据实际字符串类型调整

PREPARE stmt FROM @sql;
EXECUTE stmt;
DEALLOCATE PREPARE stmt;

注意：不同数据库的系统表和数据类型名称略有差异（比如PostgreSQL数据类型为character varying、SQL Server用sys.columns），需对应调整。

2. 大数据量下SELECT * vs 指定5列加排序的效率差异 #

两者效率差异显著，指定列的查询效率远高于SELECT *，核心原因：

• 数据IO与传输：SELECT *会读取所有列数据，磁盘IO和网络传输（远程连接场景）开销成倍增加；指定5列仅读取必要数据，IO开销大幅降低。
• 排序资源占用：排序时数据库需将数据加载到内存（或临时磁盘），列越多占用的内存/磁盘空间越大，内存不足会触发磁盘排序，速度比内存排序慢数倍；指定5列能减少排序所需资源，避免或减少磁盘排序。
• 索引利用：如果排序字段和指定的5列能组成覆盖索引，数据库可直接从索引获取数据，无需回表查询原数据；而SELECT *必然需要回表（除非所有列都在索引中，几乎不可能），额外增加IO开销。

3. 开启过滤返回更少结果是否更耗资源？ #

分两种情况判断：

• 过滤条件命中索引：比如status = 'Finished'有索引时，数据库会先通过索引快速筛选符合条件的行，再做模糊匹配和排序，整体资源消耗远低于无过滤（无过滤需全表扫描+全量排序），返回结果越少，后续处理开销越小。
• 过滤条件无法命中索引：比如LIKE '%tshirt%'这类前缀通配的模糊匹配（无法利用普通索引），数据库需全表扫描每行判断条件，但只要过滤后结果集远小于全表，后续排序、返回的开销会大幅降低，整体资源消耗仍低于无过滤全表排序。只有当过滤条件本身需要极复杂计算，且过滤后结果集与全表规模相近时，才可能比无过滤更耗资源，但你的场景不存在这种情况。

内容的提问来源于stack exchange，提问作者PolenQuick