mysql超长sql查询_实际限制SQL查询的长度(特别是MySQL)

bd96500e110b49cbb3cd949968f18be7.png

Is it particularly bad to have a very, very large SQL query with lots of (potentially redundant) WHERE clauses?

For example, here's a query I've generated from my web application with everything turned off, which should be the largest possible query for this program to generate:

SELECT *

FROM 4e_magic_items

INNER JOIN 4e_magic_item_levels

ON 4e_magic_items.id = 4e_magic_item_levels.itemid

INNER JOIN 4e_monster_sources

ON 4e_magic_items.source = 4e_monster_sources.id

WHERE (itemlevel BETWEEN 1 AND 30)

AND source!=16 AND source!=2 AND source!=5

AND source!=13 AND source!=15 AND source!=3

AND source!=4 AND source!=12 AND source!=7

AND source!=14 AND source!=11 AND source!=10

AND source!=8 AND source!=1 AND source!=6

AND source!=9 AND type!='Arms' AND type!='Feet'

AND type!='Hands' AND type!='Head'

AND type!='Neck' AND type!='Orb'

AND type!='Potion' AND type!='Ring'

AND type!='Rod' AND type!='Staff'

AND type!='Symbol' AND type!='Waist'

AND type!='Wand' AND type!='Wondrous Item'

AND type!='Alchemical Item' AND type!='Elixir'

AND type!='Reagent' AND type!='Whetstone'

AND type!='Other Consumable' AND type!='Companion'

AND type!='Mount' AND (type!='Armor' OR (false ))

AND (type!='Weapon' OR (false ))

ORDER BY type ASC, itemlevel ASC, name ASC

It seems to work well enough, but it's also not particularly high traffic (a few hundred hits a day or so), and I wonder if it would be worth the effort to try and optimize the queries to remove redundancies and such.

解决方案

Reading your query makes me want to play an RPG.

This is definitely not too long. As long as they are well formatted, I'd say a practical limit is about 100 lines. After that, you're better off breaking subqueries into views just to keep your eyes from crossing.

I've worked with some queries that are 1000+ lines, and that's hard to debug.

By the way, may I suggest a reformatted version? This is mostly to demonstrate the importance of formatting; I trust this will be easier to understand.

select *

from

4e_magic_items mi

,4e_magic_item_levels mil

,4e_monster_sources ms

where mi.id = mil.itemid

and mi.source = ms.id

and itemlevel between 1 and 30

and source not in(16,2,5,13,15,3,4,12,7,14,11,10,8,1,6,9)

and type not in(

'Arms' ,'Feet' ,'Hands' ,'Head' ,'Neck' ,'Orb' ,

'Potion' ,'Ring' ,'Rod' ,'Staff' ,'Symbol' ,'Waist' ,

'Wand' ,'Wondrous Item' ,'Alchemical Item' ,'Elixir' ,

'Reagent' ,'Whetstone' ,'Other Consumable' ,'Companion' ,

'Mount'

)

and ((type != 'Armor') or (false))

and ((type != 'Weapon') or (false))

order by

type asc

,itemlevel asc

,name asc

/*

Some thoughts:

==============

0 - Formatting really matters, in SQL even more than most languages.

1 - consider selecting only the columns you need, not "*"

2 - use of table aliases makes it short & clear ("MI", "MIL" in my example)

3 - joins in the WHERE clause will un-clutter your FROM clause

4 - use NOT IN for long lists

5 - logically, the last two lines can be added to the "type not in" section.

I'm not sure why you have the "or false", but I'll assume some good reason

and leave them here.

*/

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值