Hangisi en hızlı? `Table 'dan SQL_CALC_FOUND_ROWS veya SELECT COUNT (*)

Genellikle disk belleği olarak kullanılan bir SQL sorgusu tarafından döndürülecek satır sayısını sınırladığınızda, toplam kayıt sayısını belirlemek için iki yöntem vardır:

Yöntem 1

SQL_CALC_FOUND_ROWSSeçeneği orijinal belgeye dahil edin SELECTve ardından çalıştırarak toplam satır sayısını elde edin SELECT FOUND_ROWS():

SELECT SQL_CALC_FOUND_ROWS * FROM table WHERE id > 100 LIMIT 10;
SELECT FOUND_ROWS();  

Yöntem 2

Sorguyu normal şekilde çalıştırın ve ardından çalıştırarak toplam satır sayısını alın SELECT COUNT(*)

SELECT * FROM table WHERE id > 100 LIMIT 10;
SELECT COUNT(*) FROM table WHERE id > 100;  

Hangi yöntem en iyi / en hızlı?

Değişir. Bu konuyla ilgili MySQL Performans Blog yayınına bakın: http://www.mysqlperformanceblog.com/2007/08/28/to-sql_calc_found_rows-or-not-to-sql_calc_found_rows/

Kısa bir özet: Peter bunun dizinlerinize ve diğer faktörlere bağlı olduğunu söylüyor. Gönderiye yapılan yorumların çoğu, SQL_CALC_FOUND_ROWS'un iki sorgu çalıştırmaktan neredeyse her zaman daha yavaş - bazen 10 kata kadar daha yavaş olduğunu söylüyor.

"En iyi" yaklaşımı seçerken, hızdan daha önemli bir husus, kodunuzun sürdürülebilirliği ve doğruluğu olabilir. Öyleyse, SQL_CALC_FOUND_ROWS tercih edilir, çünkü yalnızca tek bir sorgu tutmanız gerekir. Tek bir sorgu kullanmak, ana ve sayım sorguları arasında yanlış bir COUNT değerine yol açabilecek küçük bir fark olasılığını tamamen engeller.

MySQL, SQL_CALC_FOUND_ROWS8.0.17 ve sonraki sürümlerle işlevselliği kullanımdan kaldırmaya başladı .

Bu nedenle, her zaman sorgunuzu çalıştırmayı LIMITve sonra ek satırlar olup olmadığını belirlemek için COUNT(*)ve olmadan ikinci bir sorgu kullanmayı düşünmek tercih edilirLIMIT .

Gönderen docs :

SQL_CALC_FOUND_ROWS sorgu değiştiricisi ve ona eşlik eden FOUND_ROWS () işlevi MySQL 8.0.17'den itibaren kullanımdan kaldırılmıştır ve gelecekteki bir MySQL sürümünde kaldırılacaktır.

COUNT (*) belirli optimizasyonlara tabidir. SQL_CALC_FOUND_ROWS bazı optimizasyonların devre dışı bırakılmasına neden olur.

Bunun yerine şu sorguları kullanın:

SELECT * FROM tbl_name WHERE id > 100 LIMIT 10;
SELECT COUNT(*) WHERE id > 100;

Ayrıca, MySQL WL # 12615'teSQL_CALC_FOUND_ROWS açıklandığı gibi, genel olarak daha fazla sorun yaşadığı gözlemlenmiştir :

SQL_CALC_FOUND_ROWS'un bir takım sorunları vardır. Her şeyden önce, yavaş. COUNT ( ), sonuç kümesinin tamamını (ör. Filesort) ararken gerçekleştirilemeyen optimizasyonları kullanabildiğinden, sorguyu aynı sorgu için LIMIT ve ardından ayrı bir SELECT COUNT ( ) çalıştırmak daha ucuz olacaktır. COUNT (*) için atlanabilirken, CALC_FOUND_ROWS ile doğru sonucu garanti etmek için bazı dosya sırası optimizasyonlarını devre dışı bırakmalıyız)

Daha da önemlisi, bazı durumlarda çok net olmayan anlambilimine sahiptir. Özellikle, bir sorguda birden çok sorgu bloğu varsa (örn. UNION ile), geçerli bir sorgu oluştururken aynı zamanda “olurdu” satır sayısını hesaplamanın bir yolu yoktur. Yineleyici yürütücü bu tür sorgulara doğru ilerlerken, aynı semantiği korumaya çalışmak gerçekten zordur. Ayrıca, sorguda birden fazla LIMIT varsa (örneğin, türetilmiş tablolar için) SQL_CALC_FOUND_ROWS'un hangisine başvurması gerektiği açık değildir. Bu nedenle, bu tür önemsiz olmayan sorgular, yineleyici yürütücüsünde daha önce sahip olduklarına kıyasla mutlaka farklı semantikler alacaktır.

Son olarak, SQL_CALC_FOUND_ROWS'un yararlı göründüğü kullanım durumlarının çoğu LIMIT / OFFSET dışındaki mekanizmalarla çözülmelidir. Örneğin, bir telefon defteri kayıt numarasına göre değil, harfle (hem UX açısından hem de dizin kullanımı açısından) sayfalandırılmalıdır. Tartışmalar, posta numarasına göre sayfalandırılmış değil, tarihe göre giderek artan bir şekilde sonsuz kaydırma sırasına göre sıralanır (yine dizin kullanımına izin verir). Ve bunun gibi.

Aşağıdaki makaleye göre: https://www.percona.com/blog/2007/08/28/to-sql_calc_found_rows-or-not-to-sql_calc_found_rows/

Where yan tümcenizde bir INDEX varsa (durumunuzda id dizinlenmişse), SQL_CALC_FOUND_ROWS kullanmamanız ve bunun yerine 2 sorgu kullanmamanız, ancak nerede yan tümcesine koyduğunuza ilişkin bir indeksiniz yoksa daha iyi olur (sizin durumunuzda id) SQL_CALC_FOUND_ROWS kullanmak daha verimlidir.

IMHO, neden 2 sorgu

SELECT * FROM count_test WHERE b = 666 ORDER BY c LIMIT 5;
SELECT count(*) FROM count_test WHERE b = 666;

SQL_CALC_FOUND_ROWS kullanmaktan daha hızlı

SELECT SQL_CALC_FOUND_ROWS * FROM count_test WHERE b = 555 ORDER BY c LIMIT 5;

özel bir durum olarak görülmelidir.

Gerçekte, SİPARİŞ + SINIR ile eşdeğer örtük olanın seçiciliğine kıyasla WHERE maddesinin seçiciliğine bağlıdır.

Arvids'in yorumda söylediği gibi ( http://www.mysqlperformanceblog.com/2007/08/28/to-sql_calc_found_rows-or-not-to-sql_calc_found_rows/#comment-1174394 ), EXPLAIN'in kullandığı ya da kullanmadığı gerçeği, bir geçici tablo, SCFR'nin daha hızlı olup olmayacağını bilmek için iyi bir temel olmalıdır.

Ancak, eklediğim gibi ( http://www.mysqlperformanceblog.com/2007/08/28/to-sql_calc_found_rows-or-not-to-sql_calc_found_rows/#comment-8166482 ), sonuç gerçekten duruma bağlıdır. Belirli bir sayfa için, “ilk 3 sayfa için 2 sorgu kullanın; sonraki sayfalar için bir SCFR kullanın ”!

Gereksiz bazı SQL'leri kaldırmak ve daha sonra COUNT(*)daha hızlı olacaktır SQL_CALC_FOUND_ROWS. Misal:

SELECT Person.Id, Person.Name, Job.Description, Card.Number
FROM Person
JOIN Job ON Job.Id = Person.Job_Id
LEFT JOIN Card ON Card.Person_Id = Person.Id
WHERE Job.Name = 'WEB Developer'
ORDER BY Person.Name

Sonra gereksiz parça olmadan sayın:

SELECT COUNT(*)
FROM Person
JOIN Job ON Job.Id = Person.Job_Id
WHERE Job.Name = 'WEB Developer'

Kıyaslama yapabileceğiniz başka seçenekler de vardır:

1.) Bir pencere fonksiyonu gerçek boyutu doğrudan döndürecektir (MariaDB'de test edilmiştir):

SELECT 
  `mytable`.*,
  COUNT(*) OVER() AS `total_count`
FROM `mytable`
ORDER BY `mycol`
LIMIT 10, 20

2.) Kutunun dışında düşünmek, çoğu zaman kullanıcıların tablonun EXACT boyutunu bilmesine gerek yoktur , yaklaşık bir değer genellikle yeterlidir.

SELECT `TABLE_ROWS` AS `rows_approx`
FROM `INFORMATION_SCHEMA`.`TABLES`
WHERE `TABLE_SCHEMA` = DATABASE()
  AND `TABLE_TYPE` = "BASE TABLE"
  AND `TABLE_NAME` = ?