SQLx 查询 MySQL 向量列，报 unknown column type 0xf2

MySQL 表加了 VECTOR 列，SQLx 的 SELECT * 开始报 unknown column type 0xf2。改成只查普通列又正常，甚至还没有取出向量字段就失败，应先检查驱动读取列定义的阶段。

MySQL 9.0 起支持的 VECTOR 使用协议类型编号 0xf2。SQLx 0.8.6 存在这条边界，正式 0.9.0 的 MySQL ColumnType 仍没有对应编号。raw_sql 也需要解析结果列定义，因此把预处理改成文本协议并不能绕开它。

需要保留向量时，让结果列采用可读取的表示

如果当前接口可以接收文本向量，可在投影中显式转换，而不是从结果里删掉向量：

SELECT id, VECTOR_TO_STRING(v) AS v_text
FROM t
WHERE id = ?;

t、id 和 v 是示例表列，实际查询应保留原过滤、参数绑定与权限范围。VECTOR_TO_STRING 是 MySQL 向量函数，返回可读的数字数组文本，使该结果列不再暴露原始 VECTOR 类型编号。

Rust 接收时可把非空文本按 JSON 数组读取为明确的数值向量，再验证维度与数值范围。列允许 SQL NULL 时先用 Option 接收，保留 NULL 与空向量的区别；不要用空字符串代替缺失，也不要将 null 一律补成全零向量。

文本投影改变了传输形式

数据库中的 VECTOR 列仍保留原类型，修改的是这条查询的返回表示。文本可能增加传输与解析成本，数值展示也不等于原始二进制逐字保留。需要二进制精确往返或极高吞吐的接口，应另核对驱动的正式支持与编码契约，不能把文本方案描述成完全等价的底层类型支持。

避免继续使用 SELECT 星号：除了未知类型，后来新增列也可能改变映射与返回量。只列出业务需要的普通字段和明确转换的向量，但不能借此漏掉下游必需的数据。

MariaDB 的同名 VECTOR 可能以二进制字符串类型发送，和这里的 MySQL 协议编号不同。换一个数据库测试成功，不足以证明原 SQLx 读取已支持 MySQL VECTOR。

在隔离查询中核对普通字段、完整向量、维度、负值与应用允许的空值；下游使用相似度时，再检查结果含义没有因解析精度或维度错位改变。保存原 SQL 与映射，切换读取契约后一起更新调用方；恢复旧 SQL 会重新暴露未知类型错误，不应作为长期绕过。