mysql 内连接语句和内存过度使用!

发布于 2024-09-15 12:03:40 字数 828 浏览 9 评论 0原文

我运行下面的查询从 3 个 mysql 表中获取,它工作正常,但它增加了内存使用量,有时需要 10 秒才能开始加载页面

  INNER JOIN table_tags AS ntg ON (ns.tags = '' OR CONCAT(' ',COALESCE(ns.tags,' '),' ') LIKE CONCAT('% ',ntg.tid,' %'))
  INNER JOIN table_topics AS nto ON (ns.associated = '' OR CONCAT(' ',COALESCE(ns.associated,'-'),' ') LIKE CONCAT('%',nto.topicid,'%' ))

问题 处于 Inner Join statemnet 中,如果我删除

ns.tags = '' 或

ns.associate = '' 或

内存过度使用问题将得到解决,但无法显示带有空标签字段的故事

是否有其他方法可以编写以下语句来包含所有故事,甚至那些没有标签的故事!?

  INNER JOIN table_tags AS ntg ON (ns.tags = '' OR CONCAT(' ',COALESCE(ns.tags,' '),' ') LIKE CONCAT('% ',ntg.tid,' %'))

我的标签 id 存储在 table_ns 中,如 ( 14 17 2 ) 以空格分隔

im running bellow query to fetch from 3 mysql tables and it works fine but it increases memory usage and sometime it takes 10 seconds to start loading the page

  INNER JOIN table_tags AS ntg ON (ns.tags = '' OR CONCAT(' ',COALESCE(ns.tags,' '),' ') LIKE CONCAT('% ',ntg.tid,' %'))
  INNER JOIN table_topics AS nto ON (ns.associated = '' OR CONCAT(' ',COALESCE(ns.associated,'-'),' ') LIKE CONCAT('%',nto.topicid,'%' ))

problem is in Inner Join statemnet and if i remove

ns.tags = '' OR

and

ns.associated = '' OR

the memory overuse problem will be fixed but cant show stories with empty tag field

is there any other way to write bellow statement to include all stories even those with no tags !?

  INNER JOIN table_tags AS ntg ON (ns.tags = '' OR CONCAT(' ',COALESCE(ns.tags,' '),' ') LIKE CONCAT('% ',ntg.tid,' %'))

my tags id are stored in table_ns like ( 14 17 2 ) seprated with space

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

新人笑 2024-09-22 12:03:40

您的条件 ns.tags = '' OR ... 意味着如果 ns.tags = '' 为 true,则 table_stories 中的此记录将与 all< /em> table_tags 中的记录。与 ns.linked = '' OR .. 相同。这可以轻松地“创建”大量结果集,但这很可能不是您想要的。
如果您真的不想/无法更改/规范化表结构(正如您在对我之前的答案的评论中所述),我最好的猜测是使用两个 LEFT JOIN 类似:

SELECT
  ns.*,
  ntg.tid,
  nto.topicid,
  group_concat(DISTINCT ntg.tag ) as mytags,
  group_concat(DISTINCT ntg.slug ) as tagslug,
  group_concat(DISTINCT nto.topicname ) as mytopics,
  group_concat(DISTINCT nto.slug ) as topicslug,
  ns.counter AS counter_num
FROM
  table_stories AS ns
LEFT JOIN
  table_tags AS ntg
ON
  CONCAT(' ', ns.tags,' ') LIKE CONCAT('% ',ntg.tid,' %')
LEFT JOIN
  table_topics AS nto
ON
  CONCAT(' ', ns.associated, ' ') LIKE CONCAT('%',nto.topicid,'%' )
WHERE
  time <= '4711'
GROUP BY
  ns.sid
ORDER BY
  ns.sid DESC,ns.hotnews DESC

但是 MySQL 不能为此使用索引,因此查询将导致全表扫描。它还需要临时表和文件排序,即查询相对较慢。
在不改变表结构但将数据格式从1 2 3更改为1,2,3的情况下,你至少可以摆脱< code>Concat() 和 LIKE 通过使用稍快的 FIND_IN_SET(str, strlist)


只是为了完整起见,以防您改变主意: http://en.wikipedia.org/wiki/Database_normalization

Your condition ns.tags = '' OR ... means that if ns.tags = '' is true this record from table_stories will be joined with all the records in table_tags. Same with ns.associated = '' OR ... This can easily "create" huuuge result sets and that's most likely not what you want.
If you really don't want/can't change/normalize the table structure (as you've stated in a comment to my previous answer) my best guess is to use two LEFT JOINs like:

SELECT
  ns.*,
  ntg.tid,
  nto.topicid,
  group_concat(DISTINCT ntg.tag ) as mytags,
  group_concat(DISTINCT ntg.slug ) as tagslug,
  group_concat(DISTINCT nto.topicname ) as mytopics,
  group_concat(DISTINCT nto.slug ) as topicslug,
  ns.counter AS counter_num
FROM
  table_stories AS ns
LEFT JOIN
  table_tags AS ntg
ON
  CONCAT(' ', ns.tags,' ') LIKE CONCAT('% ',ntg.tid,' %')
LEFT JOIN
  table_topics AS nto
ON
  CONCAT(' ', ns.associated, ' ') LIKE CONCAT('%',nto.topicid,'%' )
WHERE
  time <= '4711'
GROUP BY
  ns.sid
ORDER BY
  ns.sid DESC,ns.hotnews DESC

But MySQL can't use indices for this, so the query will result in full table scans. It will also need temporary tables and filesort, i.e. the query is relatively slow.
Without changing the table structure but the format of the data from 1 2 3 to 1,2,3 you can at least get rid of Concat() and LIKE by using the slightly faster FIND_IN_SET(str, strlist).


Just for completeness and in case you change your mind: http://en.wikipedia.org/wiki/Database_normalization

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文