大哥们!大量数据 中使用 distinct 或 Group By ,应该怎么办呀?

Longchao 2009-03-09 06:50:40
我两个表,
一个是 分类表 Cls
一个是 产品表 Pro

分类表 Cls 里有 8000 条信息
产品表 Pro 里有 400多万条信息

产品表 Pro 里有一个字段 Pro.ClsId 用来关联Cls.Id的

现在要执行:
Select distinct(ClsId) From [Pro] Where CONTAINS(Name , '锁')
或
Select ClsId From [Pro] Where CONTAINS(Name , '锁') Group By ClsId

总是查询超时,请问各位大大,有没有办法解决呢?
能解决就可以了。不管用什么方法!
急急急。。。。
...全文
485 12 打赏 收藏 举报
写回复
用AI写文章
12 条回复
切换为时间正序
请发表友善的回复…
发表回复
htl258_Tony 2009-03-10
  • 打赏
  • 举报
回复
[Quote=引用 11 楼 sdhdy 的回复:]
除了索引外,再想想别的办法,比如为什么Pro表要放400W记录?
[/Quote]
赞同,应该想想办法,比如创建一个历史表,把不常查询的存放在历史表,查询的时候同样可以调用。
sdhdy 2009-03-10
  • 打赏
  • 举报
回复
除了索引外,再想想别的办法,比如为什么Pro表要放400W记录?
wojiaochenglong 2009-03-10
  • 打赏
  • 举报
回复
索引是应该建了,另外,CONTAINS(Name , '锁')耗时多
Longchao 2009-03-10
  • 打赏
  • 举报
回复
UP
sigmod 2009-03-09
  • 打赏
  • 举报
回复
这是fulltext search,不是 like '%锁%', 全文索引会被利用的

[Quote=引用 7 楼 ruihuahan 的回复:]
CONTAINS(Name , '锁')
==========================
这个条件很不好,能换成类似 like ‘锁%'吗?
[/Quote]
ruihuahan 2009-03-09
  • 打赏
  • 举报
回复
CONTAINS(Name , '锁')
==========================
这个条件很不好,能换成类似 like ‘锁%'吗?
肥龙上天 2009-03-09
  • 打赏
  • 举报
回复

没有必要时不要用DISTINCT和ORDER BY,这些动作可以改在客户端执行。它们增加了额外的开销。这同UNION和UNION ALL一样的道理。

一般在GROUP BY和HAVING字句之前就能剔除多余的行,所以尽量不要用它们来做剔除行的工作。他们的执行顺序应该如下最优:
select 的Where字句选择所有合适的行,Group By用来分组个统计行,Having字句用来剔除多余的分组。
这样Group By和Having的开销小,查询快.对于大的数据行进行分组和Having十分消耗资源。如果Group BY的目的不包括计算,只是分组,那么用Distinct更快
Longchao 2009-03-09
  • 打赏
  • 举报
回复
建立索引了
等不到来世 2009-03-09
  • 打赏
  • 举报
回复
换其它条件也超时吗?
重建一下全文索引试试。调整一下因子
sigmod 2009-03-09
  • 打赏
  • 举报
回复
读多,还是写多?
如果读多,建materialized view

IF OBJECT_ID('dbo.m_view_pro') IS NOT NULL
DROP VIEW dbo.m_view_pro;
GO

CREATE VIEW dbo.m_view_pro
WITH SCHEMABINDING
AS
Select distinct(ClsId) From [Pro] Where CONTAINS(Name , '锁')
Go

CREATE VIEW dbo.m_view_pro_distinct
WITH SCHEMABINDING
AS
SElECT ClsId FROM [Pro] WHERE CONTAINS(Name , '锁') Group BY ClsId
Go

CREATE UNIQUE CLUSTERED INDEX idx_clsid
ON dbo.m_view_pro_distinct(ClsId);
Go

CREATE UNIQUE CLUSTERED INDEX idx_clsid
ON dbo.m_view_pro(ClsId);
Go
htl258_Tony 2009-03-09
  • 打赏
  • 举报
回复
CREATE INDEX au_id_ind ON  [Pro] (name)
--再
Select distinct(ClsId) From [Pro] Where CONTAINS(Name , '锁')
--或
Select ClsId From [Pro] Where CONTAINS(Name , '锁') Group By ClsId
htl258_Tony 2009-03-09
  • 打赏
  • 举报
回复
400多万的表有建立索引吗?
Name ,ClsId
附训练好的 YOLO 权重与 PyQt 可视化检测界面,页面底部含可视化效果预览,毕设/课设开箱即用。 【数据集概况】 · 检测类别(中文):[领航车(leader)] · 训练集:414 张 · 验证集:39 张 · 测试集:20 张 · 总计:473 张 该数据集聚焦于室内走廊环境中对领航车的精准识别与定位,具备高度场景专一性与实际应用价值。图像采集于光线均匀、结构规整的建筑内部通道,背景干扰因素少,有利于模型在复杂环境下的目标提取能力训练。领航车作为核心检测对象,在不同距离和角度下均被清晰标注,为智能导航系统、自动化引导设备等提供可靠的数据支持。... 【训练曲线与评估图】 【模型训练配置】 参数 | 值 模型 | yolo26n 训练轮数 | 100 epochs 输入尺寸 | 640x640 批次大小 | 24 优化器 | auto 初始学习率 | 0.01 训练设备 【关键指标汇总】 训练了 77 个 epoch,最终轮指标: 指标 | 数值 mAP50 | **0.9950** mAP50-95 | 0.9141 Precision | 0.9985 Recall | 1.0000 train/box_loss | 0.5224 train/cls_loss | 0.2526 val/box_loss | 0.4307 val/cls_loss | 0.1407 【训练过程分析】 77 轮训练后 mAP50 达到 0.9950,模型收敛良好。Loss 曲线前段快速下降,后段趋于平稳,val_loss 无反弹,没有明显过拟合。mAP50-95 为 0.9141,和 mAP50 差距仅 0.08,框的定位精度也很扎实。 【模型性能评估】 Precision 0.9985、Recall 1.000... 使用场景:毕业设计、课程设计、深度学习入门、工业场景落地验证。

27,579

社区成员

发帖
与我相关
我的任务
社区描述
MS-SQL Server 应用实例
社区管理员
  • 应用实例社区
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧