赞助商

SELECTs -- do's and don'ts

发布时间:2019-02-25 发布网站:脚本之家
脚本之家收集整理的这篇文章主要介绍了SELECTs -- do's and don'ts脚本之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

原文地址:http://mysql.rjweb.org/doc.php/ricksrots

Brought to you by Rick James

Here are 160+ tips,tricks,suggestions,etc. They come from a decade of improving performance in MySQL in thousands of situations. There are exceptions to the statements below,but they should help guide you into better understanding how to effectively use MySQL. 

SELECTs -- do's and don'ts

RoTs dt >= '2010-02-01' AND dt < '2010-02-01' + INTERVAL 7 DAY     ⚈  ORDER BY NULL -- a little-known trick to avoid GROUP BY doing a sort (if there is another way).     ⚈  WHERE (a,b) > (7,8) is poorly optimized     ⚈  Gather these to study a slow query: SHOW CREATE TABLE,SHOW TABLE STATUS,EXPLAIN.     ⚈  Do not use OFFSET for pagination -- continue where you "left off"     ⚈  Don't mix DISTINCT and GROUP BY     ⚈  Be explicit about UNION ALL vs UNION DISTINCT -- it makes you think about which to use     ⚈  Do not use SELECT * except for debugging or when fetching into a hash.     ⚈  VIEWs are poorly optimized     ⚈  A subquery in the FROM clause may be useful for retrieving BLOBs without sorting them: Speed up a query by first finding the IDs,then self-JOIN to fetch the rest. ORDER BY id LIMIT 30,10to find the 4th page of 10 items. But it is so inefficient,especially when you have thousands of pages. The thousandth page has to read (at some level) all the pages before it. "Left off" refers to having the "Next" button on one page give the id (or other sequencing info) of where the next page can be found. Then that page simply does WHERE id > $leftoff ORDER BY id LIMIT 10 </tr>

INDEXing

Discussion
RoTs Data_length     ⚈  5 fields in a compound index seems "too many"     ⚈  Having no compound indexes is a clue that you do not understand their power. INDEX(a,b) may be much better than INDEX(a),INDEX(b)     ⚈  INDEX(a,b) covers for INDEX(a),so drop the latter.     ⚈  2x speedup when "Using index" (a "covering" index)     ⚈  Akiban (3rd party) "groups" tables together,interleaved,to improve JOIN performance.     ⚈  FULLTEXT (MyISAM) -- watch out for ft_min_word_len=4,stopwords,and 50% rule     ⚈  A FULLTEXT index will be used before any other index.     ⚈  FULLTEXT -- consider Syphinx,Lucene,etc (3rd Party) all the fields needed in a SELECT are included in the INDEX.</tr>

ENGINE Differences

Discussion
RoTs </tr>

Optimizations,and not

Discussion
RoTs If you can arrange for rows to be "adjacent" to each other,then one disk fetch will bring in many rows (10x speedup). "Batched" INSERTs are where one INSERT statement has multiple rows. Nearly all of the performance benefit is in the first 100 rows; going beyond 1000 is really getting into 'diminishing returns'. Furthermore,in a Replication environment,a huge INSERT would cause the Slave to get 'behind'.  </tr>

PARTITIONing

Discussion
RoTs 1M rows     ⚈  No more than 50 PARTITIONs on a table (open,show table status,are impacted) (fixed in 5.6.6?)     ⚈  PARTITION BY RANGE is the only useful method.     ⚈  SUBPARTITIONs are not useful.     ⚈  The partition field should not be the field first in any key.     ⚈  It is OK to have an AUTO_INCREMENT as the first part of a compound key,or in a non-UNIQUE index. could INSERT a duplicate id if you explicitly provide the number.  </tr>

Memory Usage

Discussion
RoTs 1/sec,increase table_open_cache.     ⚈  Turn off the Query Cache. Type=off and size=0  </tr>

Character Sets

Discussion
RoTs utf8_general_ci > utf8_bin     ⚈  Debug stored data via HEX(col),LENGTH(col),CHAR_LENGTH(col)     ⚈  Do not use utf8 for hex or ascii strings (GUID,md5,ip address,country code,postal code,etc.) = CHAR_LENGTH(col): with European text '=' for latin1,'>' for utf8.  </tr>

Datatypes - Directly supported

Discussion
RoTs WHERE a.start < b.end AND a.end > b.start     ⚈  Don't be surprised by AUTO_INCREMENT values after uncommon actions.  More cacheable --> Faster. An AUTO_INCREMENT is very non-random,at least for inserting. Each new row will be on the 'end' of the table. That is,the last block is "hot spot". Thanks to caching very little I/O is needed for an AUTO_INCREMENT index. VARCHAR(255) for everything is tempting. And for "small" tables it won't hurt. For large tables one needs to consider what happens during the execution of complex SELECTs. If a "temporary" table is implicitedly generated,the VARCHAR will take 767 bytes in the temp table (2+3*255) bytes. 2=VAR overhead,3=utf8 expansion,255=your limit. A DELETE of the last row may or many not burn that AUTO_INCREMENT id. INSERT IGNORE burns ids because it allocates values before checking for duplicate keys. A Slave may see InnoDB ids arriving out of order (because transactions arrive in COMMIT order). A ROLLBACK (explicit or implicit) will burn any ids already allocated to INSERTs. REPLACE = DELETE + INSERT,so the INSERT comments apply to REPLACE. After a crash,the next id to be assigned may or may not be what you expect; this varies with Engine.  </tr>

Datatypes - Implicit

Discussion
RoTs Since GUID,UUID,MD5,and SHA1 are fixed length,VAR is not needed. If they are in hex,don't bother with utf8; use BINARY or CHAR CHARSET ascii. Images could be stored in BLOB (not TEXT). This better assures referential integrity (not accidentally deleting the metadata or image,but not both). On the other hand,it is clumsy. With files,an img tag can point directly to the image on disk.  </tr>

Hardware

Discussion
RoTs 8 cores degrade performance. (Changes coming in XtraDB,5.6,MariaDB,etc) (5.6 claims to be good to 48 cores - YMMV; 5.7 claims 64)     ⚈  A single connection will not use more than one core. Not even with UNION or PARTITION.     ⚈  Don't put a cache in front of a cache     ⚈  10x speed up when disk blocks are cached,so... Time a query twice -- first will get things cached,second will do no I/O     ⚈  Benchmark with "SELECT SQL_NO_CACHE ..." (to avoid Query cache)  </tr>

PXC / Galera

Discussion
RoTs or slower than traditional replication     ⚈  AUTO_INCREMENT values won't be consecutive     ⚈  Handle "critical reads" using wsrep_causal_reads     ⚈  ALTERs need to be handled differently (see RSU vs TOI)     ⚈  Lots of tricks are based on: remove from cluster + do stuff + add back to cluster     ⚈  Minimal HA: 1 node in each of 3 datacenters; one could be just a grabd  </tr>

Data Warehouse

Discussion
RoTs </tr>

Miscellany

Discussion
RoTs 10,you may be in serious trouble.     ⚈  SHOW PROCESSLIST with some threads "Locked" -- some other thread is hogging something.     ⚈  SHOW PROCESSLIST may fail to show the locking thread -- it is Sleeping,but not yet COMMITted.     ⚈  >90% CPU --> investigate queries/indexes. (The SlowLog also catches such.)     ⚈  >90% of one core -- since MySQL won't use multiple cores in a single connection,this indicates an inefficient query. (Eg,12% overall on an 8-core box is probably consuming one core.)     ⚈  >90% I/O -- tuning,overall schema design,missing index,etc.     ⚈  "NoSQL" is a catchy phrase looking for a definition. By the time NoSQL gets a definition,it will look a lot like an RDBMS solution. MariaDB 5.3's "Dynamic Columns" eats into a big excuse for "NoSQL".  </tr>

总结

以上是脚本之家为你收集整理的SELECTs -- do's and don'ts全部内容,希望文章能够帮你解决SELECTs -- do's and don'ts所遇到的程序开发问题。

如果觉得脚本之家网站内容还不错,欢迎将脚本之家网站推荐给程序员好友。

本图文内容来源于网友网络收集整理提供,作为学习参考使用,版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ:76874919,请注明来意。
标签:
Discussion