Python读取SQL表数据时date、time、Decimal类型自动转换异常问题

• 存储侧：SQL数据库中的表包含DATE、TIME、DECIMAL三类原生字段，直接在SQL客户端执行查询时，所有字段的返回格式、数值完全符合预期，无异常。
• Python读取侧异常表现：
  • 原本的DATE字段被自动转换为Pythondatetime.datetime类型
  • 原本的TIME字段被自动转换为Pythondatetime.timedelta类型
  • 原本的DECIMAL字段没有按照预期转换为float类型，反而返回标准库decimal.Decimal对象，值以字符串形式承载
• 校验依据：已留存SQL查询、Python读取的两份结果截图，两组数据行排列顺序完全对齐，同位置的匹配标注条目（SQL端黄色标注框、Python端橙色标注框）对应业务内容完全一致，但两侧展示的格式、数值存在可感知差异，暂无法定位类型转换异常的根因。

驱动默认映射规则导致的行为差异 #

目前绝大多数Python数据库连接驱动（包括mysql-connector、psycopg2、pyodbc等）的内置类型映射逻辑，和SQL客户端的前端展示逻辑本身就存在设计差异，不属于程序bug：

• SQL客户端优先考虑展示可读性，会把DATE类型直接渲染为纯日期文本，不做额外类型转换；但Python驱动默认会给所有带日期属性的字段绑定带空时间分量的datetime对象，这就是date字段被转为datetime的核心原因。
• 针对TIME类型，驱动默认将其解析为距离当日0点的时间偏移量，直接对应Python的timedelta类型，而非datetime.time对象。
• 针对DECIMAL类型，驱动为了避免浮点运算精度丢失，默认不会将数值转为float，而是直接返回decimal.Decimal类型对象，该行为本身就是驱动的设计目标。

上层封装工具的转换规则叠加影响 #

如果通过pandas、SQLAlchemy这类上层封装读取数据，内置的默认参数会进一步放大类型差异：

• pandas默认会将SQL侧的DATE、DATETIME字段统一解析为datetime64类型，进一步偏离预期的类型结果。
• 部分低版本驱动存在TIME类型解析的已知bug，会将时间值错配为timedelta而非标准time对象，这类问题在升级驱动到稳定版本后可修复。

针对性调整方案 #

• 针对DATE字段转datetime的问题：无需修改表结构，读取后通过datetime.date()方法提取纯日期部分即可；如果需要直接拿到字符串格式，可在SQL查询语句中显式添加CAST(date_col AS CHAR)做类型转换。
• 针对TIME字段转timedelta的问题：如果需要获取标准time对象，可读取后通过timedelta的秒数分量重构时间对象；也可在驱动初始化时配置自定义类型映射，将TIME类型的转换逻辑绑定到datetime.time；如果是低版本驱动的解析bug，可升级驱动版本验证修复效果。
• 针对DECIMAL字段未转float的问题：如果业务场景对精度要求不高，可在读取完成后统一通过float(decimal_val)完成类型转换；如果对精度有严格要求，可保留Decimal类型直接参与计算，避免浮点运算产生的误差。

内容的提问来源于stack exchange，提问作者Sir-Sorg