COUNT()和COUNT(1)在InnoDB中性能几乎无差异，均走聚簇索引扫描且不判NULL；COUNT(列名)需逐行判断NULL，可能触发全表扫描而更慢；MyISAM的COUNT()缓存特性已淘汰，应专注InnoDB行为。
Java 应用里执行 MySQL 的 COUNT(*)、COUNT(1) 和 COUNT(列名)，性能差异其实不来自 Java 层，而完全由 MySQL 服务端的执行引擎（主要是 InnoDB）决定。JDBC 只是把 SQL 语句发过去、接收结果，真正耗时的是 MySQL 内部怎么扫描、判断和计数。
count(*) 和 count(1) 在 InnoDB 中几乎没区别
MySQL 官方文档明确说明：InnoDB 对 SELECT COUNT(*) 和 SELECT COUNT(1) 的处理方式完全相同。两者都走聚簇索引（主键索引）扫描，不读取具体字段值，也不做 NULL 判断——因为“行存在”本身就代表要计数。优化器会直接利用索引结构统计叶子节点数量，效率极高。
- 无论表有多少列、是否含 NULL 值，
COUNT(*)和COUNT(1)的执行计划通常都是type: index或type: NULL（表示只扫描索引，不回表） - 在 Java 代码中写
count(*)或count(1)，实际耗时基本一致，差异在微秒级，可忽略 - 阿里《Java 开发手册》强制要求用
COUNT(*)，既是标准写法，也避免团队风格混乱
count(列名) 可能明显更慢，尤其非主键列
COUNT(列名) 的语义是“统计该列值不为 NULL 的行数”，MySQL 必须逐行读取该列内容并判断是否为 NULL。如果列没有索引，就会触发全表扫描（type: ALL）；即使有索引，也要额外做 NULL 检查，比 COUNT(*) 多一步操作。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 对主键列（如
COUNT(id)），InnoDB 可能走聚簇索引，但依然要提取主键值再判 NULL，略慢于COUNT(*) - 对普通非空字段（如
COUNT(email)），若该字段无索引，性能下降更明显；若字段 NULL 值多，优化器还可能放弃索引走全表 - 在 Java 中如果误用
COUNT(status)统计总行数（而 status 允许为 NULL），不仅慢，结果还可能比预期少
MyISAM 表的特殊情况（已基本淘汰）
MyISAM 存储引擎会缓存表总行数，所以无 WHERE 条件的 COUNT(*) 是 O(1) 级别响应。但 COUNT(1) 不享受此优化（除非第一列定义为 NOT NULL），COUNT(列名) 仍需扫描。不过 MyISAM 不支持事务、已被主流项目弃用，InnoDB 才是当前默认且唯一推荐引擎。
立即学习“Java免费学习笔记（深入）”；
- Java 应用连接的 MySQL 实例，只要建表没显式指定 ENGINE=MyISAM，就默认用 InnoDB
- 不必为兼容 MyISAM 调整写法，专注 InnoDB 行为即可
Java 开发中的实用建议
写 DAO 层或 MyBatis XML 时，直接按语义选：要总行数就用 COUNT(*)，要非空值个数才用 COUNT(列名)。别为了“听说 count(1) 更快”而改写，既无收益，还降低可读性。
- MyBatis 示例：
<select id="countAll" resultType="long">SELECT COUNT(*) FROM user</select> - 避免在分页查询中写
COUNT(name)代替COUNT(*)，除非业务真要排除 name 为 NULL 的记录 - 如果统计性能瓶颈明显（如千万级表），优先考虑加覆盖索引、用近似值（
SHOW TABLE STATUS）、或异步预计算，而不是换 count 写法
