应使用SUBSTRING(id_card, 7, 4)提取18位身份证第7–10位出生年份，注意避免索引误写为6；需校验字段长度并处理NULL；计算年龄须结合月日判断是否已过生日，不可直接年份相减。
SQL视图里用 SUBSTRING 提取身份证出生年份
18位身份证第7到第10位是出生年份，直接截取即可。但要注意：不同数据库的字符串索引起始位置不同，MySQL、PostgreSQL 从 1 开始，SQL Server 也是从 1，而 Oracle 的 SUBSTR 同样是 1 起始——这点反而统一，不用额外适配。
常见错误是写成 SUBSTRING(id_card, 6, 4)（误以为索引从 0 开始），结果取到第6–9位，把年份错一位。实际必须用 SUBSTRING(id_card, 7, 4)。
- 假设字段名为
id_card，且数据已清洗（全为18位、无空格或X小写） - MySQL / PostgreSQL / SQL Server 均可用：
SUBSTRING(id_card, 7, 4) - Oracle 需用：
SUBSTR(id_card, 7, 4) - 若字段可能为空或长度不足18，加
CASE WHEN LENGTH(id_card) = 18 THEN ... ELSE NULL END防报错
计算年龄时为什么不能只用 YEAR(NOW()) - 出生年份
直接相减会忽略生日是否已过。比如今天是2025-04-05，某人身份证是1990-05-10，按 2025 - 1990 = 35 算就错了，实际才34周岁。
正确做法是结合月份和日期判断。各数据库实现略有差异：
- MySQL 可用：
TIMESTAMPDIFF(YEAR, CONCAT(SUBSTRING(id_card, 7, 4), '-', SUBSTRING(id_card, 11, 2), '-', SUBSTRING(id_card, 13, 2)), CURDATE()) - PostgreSQL 需转成
DATE类型再减：EXTRACT(YEAR FROM AGE(CURRENT_DATE, TO_DATE(SUBSTRING(id_card,7,8), 'YYYYMMDD'))) - SQL Server 更稳妥用
DATEDIFF+ 条件修正：DATEDIFF(YEAR, CAST(SUBSTRING(id_card,7,4) + '-' + SUBSTRING(id_card,11,2) + '-' + SUBSTRING(id_card,13,2) AS DATE), GETDATE()) - CASE WHEN FORMAT(GETDATE(), 'MMdd')
视图中处理15位旧身份证的兼容逻辑
15位身份证没有年份前缀（只有两位年份），且无最后一位校验码，第7–8位是年份。如果视图要同时支持15/18位，就不能硬写固定偏移。
关键判断点是长度：LENGTH(id_card) = 15 或 LEN(id_card) = 15（SQL Server）。然后分情况拼年份：
- 18位：年份 =
SUBSTRING(id_card, 7, 4) - 15位：年份 =
CONCAT('19', SUBSTRING(id_card, 7, 2))（默认19XX；极少数可能是2000年后补办的，需业务确认） - 建议统一转为4位年份后再参与年龄计算，避免后续逻辑分支爆炸
- 别忘了在视图定义里加上
WHERE id_card IS NOT NULL AND id_card != ''过滤脏数据，否则SUBSTRING在空值上可能返回异常结果（如 SQL Server 返回空串，MySQL 返回 NULL，行为不一致）
性能影响：在视图里实时计算年龄是否慢
只要身份证字段有索引，截取本身几乎无开销；但每次查视图都调用 TIMESTAMPDIFF 或 AGE 这类函数，会导致无法使用索引加速排序或条件过滤——尤其是 WHERE age > 60 这种查询，数据库只能全表计算后过滤。
更优策略是：在基础表里增加冗余列 birth_year 和 age_calc_date（记录计算时间戳），用触发器或 ETL 定期更新；视图则直接 SELECT 这些预计算字段。
如果坚持用视图纯计算，请注意：
- PostgreSQL 中对表达式建索引可行：
CREATE INDEX idx_age_expr ON user_table ((TIMESTAMPDIFF('year', ..., NOW())))，但可维护性差 - MySQL 不支持函数索引（8.0+ 支持函数索引，但仅限于存储函数，
TIMESTAMPDIFF是内置函数，仍不可索引） - 简单视图用于报表展示没问题；用于高频查询条件时，实时计算就是瓶颈
身份证年龄看似只是几个 SUBSTRING，真正卡住人的永远是边界：15/18混存、X大小写、生日未到、跨库语法、还有那个总被忽略的——NULL 和空字符串在不同数据库里对 SUBSTRING 的返回值根本不一样。
