perf(P1-11): 评估「ngram 全文检索提速搜索」——**实测不等价，故不采纳**（附证据工具）
背景
----
`api_search` 对 5 张 ACTIVE_TABLES 用 `title LIKE '%q%' OR content LIKE '%q%'`，
无法走索引；且 data 与 count 各扫一遍。数据库已有 `ngram` 插件
（`ngram_token_size=2`，STATUS=ACTIVE），故尝试用
`MATCH(title,content) AGAINST(... IN BOOLEAN MODE)` 走索引预筛、再用 LIKE 精确复核，
期望在不改变结果集的前提下提速。
实测结论：**不等价，不能采纳**
------------------------------
新增 `Scripts/bin/verify_fulltext_equivalence.py` 对 9 个查询做四写法对照
（like 基准 / 两阶段OR / 裸OR / 引号短语），结果：
| 查询 | LIKE 基准 | 两阶段 OR | 差异 |
|---|---|---|---|
| `股`（单字） | 54,015 | **1** | ★ −54,014（ngram token_size=2，单字无法命中） |
| `A股`（中英混合） | 5,882 | **0** | ★ −5,882（跨中英边界无法成 gram） |
| `人工智能`（纯中文 4 字） | 3,923 | **3,916** | ★ **−7**（即便最优情形也不精确） |
| `股市`/`涨停`/`央行`/`美股`/`IPO`/`5G` | — | 相等 | OK |
裸 MATCH（OR 语义）也**不是** LIKE 的超集（同上三项为负）→ 无法作为安全预筛。
速度确有大改善（0.25s → 0.03s），但**静默丢结果比慢更糟**，故不采纳。
处置
----
- **不修改** `api_search`（保持 `LIKE` 语义正确）
- **撤掉**本次为验证而建的 5 个 `ft_title_content` FULLTEXT 索引
（无查询会用到，只会增加高频写入表的重建与写入开销）；
`news_flash` / `news_flash_archive` 上**原有的**同名索引保持不动
- 保留 `verify_fulltext_equivalence.py` 作为可复跑的决策证据工具
当前基准（实测，5 表合计）
--------------------------
- count 语句：**0.20–0.23s**；叠加 data 查询后单次搜索约 **0.4–0.5s**
- 结论：以 5 张表（合计约 40 万行）的规模，0.25s 量级的全扫描**可接受**。
若确有提速需求，可选路径是**刻意改变检索语义**（改产品决策并同步前端提示），
或改用应用侧倒排索引 —— 二者都属独立工作量，不在"透明提速"范畴。
FinDataHub
03d7db9cd4