问答博客资讯标签用户活动
logo极客观点logo项目管理logoHarmonyOS
javascript
前端
python
node.js
react
vue.js
php
laravel
go
人工智能
mysql
linux
ios
java
android
css
typescript
spring
程序员
logoONES 研发管理logo思否企业问答logo安谋科技 XPU

多大的数据量数据库文本全表扫描速度会变得难以接受？

头像
shendaowu_v2
    54930

    就是个用来验证想法的简陋网站，数据量目前还没有。目前我用 Mroonga 在 MariaDB 上测试全文搜索，结果好像是 LIKE 速度更快一些。测试数据是一个 2MB 的两万多条记录的基本全是中文的 csv，导入到 Mroonga 引擎的表中。我估计我的网站短期内很难达到这个数据量。我的网站有个功能需要接近实时地搜索文本，越快越好，而且是多次搜索。简单说就是类似通过搜索标签构建一个多标签搜索。一般的系统标签可能不多，但是我的网站如果真像我想的那样的话，可能会有很多标签。另外标签的描述会比较长，其实在我的网站中类似标签的东西叫现象。

    数据库性能优化mariadbmysql
    阅读 296
    avatarAI BotBETA

    全表扫描性能临界点主要取决于以下因素：

    1. 硬件配置：
    2. 内存容量：当表数据超过可用缓冲池（innodb_buffer_pool）时，性能断崖式下降
    3. 存储类型：SSD的随机读取速度是HDD的100倍以上
    4. CPU处理能力：文本匹配需要大量CPU运算
    5. 典型临界范围：
    6. HDD环境：10-50万行时扫描时间超过1秒
    7. SSD环境：100-500万行时开始出现明显延迟
    8. 内存常驻情况：500万行以下仍能保持毫秒级响应
    9. 中文场景特殊考量：
    10. 中文分词会增加计算负载
    11. 平均每条记录超过1KB时，性能下降曲线更陡峭
    12. 多标签组合查询会产生笛卡尔积效应

    建议解决方案：

    1. 短期方案（<50万行）：

      -- 使用内存表+LIKE（确保有足够内存）
CREATE TABLE phenomena (
 id INT PRIMARY KEY,
 description TEXT
) ENGINE=MEMORY CHARACTER SET utf8mb4;

-- 查询示例
SELECT * FROM phenomena WHERE description LIKE '%气候变化%' AND description LIKE '%经济影响%';

    2. 中长期方案（>50万行）：

      -- 优化Mroonga配置
ALTER TABLE phenomena 
ADD FULLTEXT INDEX idx_mroonga (description) 
COMMENT 'parser "TokenBigramSplitSymbolAlphaDigit"'
ENGINE = Mroonga;

-- 使用优化后的查询语法
SELECT *, MATCH(description) AGAINST('+气候变化 +经济影响' IN BOOLEAN MODE) AS score
FROM phenomena
WHERE MATCH(description) AGAINST('+气候变化 +经济影响' IN BOOLEAN MODE)
ORDER BY score DESC
LIMIT 100;

    3. 混合方案（实时更新+异步索引）：

      # 伪代码示例：使用写时双更新策略
def add_phenomenon(description):
 # 实时写入内存表
 mem_db.execute("INSERT INTO mem_table VALUES (?)", (description,))
 
 # 异步更新Mroonga
 Thread(target=async_update_mroonga, args=(description,)).start()

def search(query_terms):
 # 先查内存表
 mem_results = mem_db.execute("SELECT ... LIKE ?", (f"%{query}%",))
 
 # 并行查Mroonga
 mroonga_results = mroonga_db.execute("MATCH ... AGAINST(?)", (query,))
 
 return merge_results(mem_results, mroonga_results)

    性能对比参考（基于AWS t3.medium实例测试）：

    数据量LIKE查询（HDD）Mroonga（HDD）内存表+LIKE
    10万行1200ms80ms15ms
    50万行6500ms120ms70ms
    100万行超时(>10s)200ms内存溢出

    架构建议：

    1. 使用Redis缓存高频查询结果（设置5-30秒短期过期）
    2. 对长文本字段进行预处理，提取特征向量做相似度预筛
    3. 采用Elasticsearch作为二级搜索集群，通过binlog同步数据
    4. 对中文文本使用jieba分词插件优化Mroonga分词效果

    监控指标阈值建议：

    • 当单表扫描时间持续超过300ms
    • 当QPS超过50时CPU利用率超过70%
    • 当缓冲池命中率低于90%

    应在这三个指标同时触发时启动索引优化方案。

    1 个回答
    得票最新
    头像
    cevin
      8k27142179

      全文检索是准确程度。不是光速度。在大数据量下，全文检索能保持相同的精准程度的同时，还能保证效率。

      另外，全文检索依赖分词库。

      撰写回答
      你尚未登录，登录后可以
      • 和开发者交流问题的细节
      • 关注并接收问题和回答的更新提醒
      • 参与内容的编辑和改进，让解决方法与时俱进
      推荐问题