Exploration des performances de pagination MySQL

La pagination est souvent utilisée dans notre programmation. Cet article vous amènera à discuter des performances de la pagination MySQL, en espérant aider tout le monde.

Méthodes de pagination courantes :

1. Méthode Escalator

La méthode de l'escalator ne propose généralement que deux modes de navigation : page précédente/page suivante. Certains produits ne proposent même pas la fonction de page précédente, mais proposent uniquement une méthode « plus/plus », et il existe également un chargement automatique déroulant. D'autres méthodes peuvent techniquement être résumées sous le nom de méthodes d'escalier mécanique.
La méthode de l'escalator est relativement simple et efficace en termes de mise en œuvre technique. Il suffit d'aller une page plus loin en fonction du décalage du dernier élément de la page actuelle. Écrit en SQL, il peut être similaire à

SELECT*FROMLIST_TABLEWHEREid> offset_id LIMIT n;

1. Méthode d'ascenseur

Une autre méthode d'acquisition de données se reflète dans le produit sous la forme d'une méthode de tournage de page précise, telle que 1, 2, 3...n. En même temps, l'utilisateur peut également. saisir directement n pages dans la navigation. La plupart des scènes en Chine utilisent des ascenseurs, mais le coût technique de mise en œuvre des ascenseurs est relativement élevé.

Dans MySQL, le b-tree généralement mentionné est généralement b+tree dans l'implémentation du moteur de stockage.

Lors de l'utilisation de la méthode de l'ascenseur, lorsque l'utilisateur spécifie de se tourner vers la nième page, il n'y a pas de moyen direct d'adresser l'emplacement. Au lieu de cela, il doit compter un par un à partir du premier étage et scanner pour compter. *page pour obtenir les données Cela vient de commencer, donc l'efficacité n'est pas élevée.

Technologie de pagination traditionnelle (méthode d'ascenseur)

Tout d'abord, le frontal doit vous transmettre l'entité de pagination et les conditions de requête

//分页实体
structFinanceDcPage{
1:i32 pageSize,//页容量
2:i32 pageIndex,//当前页索引
}

Ensuite, vous devez renvoyer le nombre total de requêtes au front-end

SELECTCOUNT(*)FROMmy_tableWHEREx= y ORDERBYid;

Puis revenez Spécifiez le nombre de pages vers le front-end :

SELECT*FROMmy_tableWHEREx= y ORDERBYdate_colLIMIT (pageIndex - 1)* pageSize, pageSize;

Les résultats interrogés par les deux instructions SQL ci-dessus doivent être renvoyés à l'entité de pagination frontale, ainsi que les résultats d'une seule page Set

//分页实体
structFinanceDcPage{
1:i32 pageSize,//页容量
2:i32 pageIndex,//当前页索引
3:i32 pageTotal,//总页数
4:i32 totalRecod,//总条数
}

Méthode de requête traditionnelle, seule la valeur pageIndex change à chaque requête, c'est-à-dire , offset limite, décalage de num

tel que limite 0,10 ; limite 10,10 ;

Les modifications ci-dessus entraîneront un écart dans le temps d'exécution de chacun. requête. Plus la valeur de décalage est grande, plus cela prendra du temps, comme limit10000 ,10 Il est nécessaire de lire 10010 éléments de données pour obtenir les 10 éléments de données souhaités.

Méthode d'optimisation

Dans la méthode traditionnelle, nous avons appris que la clé de l'efficacité est que le programme parcourt beaucoup de données inutiles et trouve la clé Cliquez sur Alors commencez ici.

S'il n'est pas nécessaire d'utiliser l'ascenseur, nous pouvons utiliser l'escalier roulant pour améliorer les performances.

Mais dans la plupart des cas, le formulaire d'ascenseur peut mieux répondre aux besoins des utilisateurs, nous devons donc trouver un autre moyen d'optimiser le formulaire d'ascenseur.

Optimisation basée sur les méthodes traditionnelles

Les méthodes d'optimisation évoquées ci-dessus sont soit difficiles à répondre aux besoins des utilisateurs, soit trop complexes à mettre en œuvre, donc Si la quantité de données n'est pas particulièrement importante, comme des millions de données, il n'est en fait pas nécessaire d'utiliser la méthode d'optimisation ci-dessus.

Les méthodes traditionnelles sont suffisantes, mais elles peuvent également nécessiter une optimisation. Par exemple :

orderby optimisation

SELECT*FROMpa_dc_flowORDERBYsubject_codeDESCLIMIT100000,5

ORDERBY est utilisé dans cette instruction Mots-clés, alors ce qu'il faut trier est très important Si vous triez des ID à incrémentation automatique, cette instruction n'a pas besoin d'être optimisée. S'il s'agit d'un index ou même d'un non-index, elle doit être optimisée.

Tout d'abord, vous devez vous assurer qu'il s'agit d'un index, sinon ce sera vraiment lent. Ensuite, s'il s'agit d'un index, mais qu'il n'est pas aussi ordonné qu'un ID auto-incrémenté, il doit alors être réécrit dans l'instruction suivante.

SELECT*FROMpa_dc_flowINNERJOIN(SELECTidFROMpa_dc_flowORDERBYsubject_codeDESCLIMIT100000,5)ASpa_dc_flow_idUSING(id);

Ce qui suit est l'EXPLAIN pour deux SQL

Nous pouvons voir sur l'image que le deuxième SQL peut scanner beaucoup moins de pages.

En fait, cela implique le problème d'optimisation de order by. L'index subject_code n'est pas utilisé dans le premier SQL. Si vous sélectionnez plutôt subject_code... l'index est utilisé. Ce qui suit est l'optimisation de la commande par.

order by后的字段，如果要走索引，须与where 条件里的某字段建立复合索引！！或者说orcerby后的字段如果要走索引排序，它要么与where条件里的字段建立复合索引【这里建立复合索引的时候，需要注意复合索引的列顺序为（where字段，order by字段），这样才能满足最左列原则，原因可能是order by字段并能算在where 查询条件中！】，要么它自身要在where条件里被引用到！

表asubject_code为普通字段,上面建有索引,id是自增主键

select*fromaorderbysubject_code//用不上索引
selectidfromaorderbysubject_code//能用上索引
selectsubject_codefromaorderbysubject_code//能用上索引
select*fromawheresubject_code= XX orderbysubject_code//能用上索引

意思是说order by 要避免使用文件系统排序，要么把order by的字段出现在select后，要么使用order by字段出现在where 条件里，要么把order by字段与where条件字段建立复合索引！

第二条sql就是巧妙的利用第二种方式利用上了索引。 select id from a order bysubject_code，这种方式

count优化

当数据量非常大时，其实可以输出总数的大概数据，利用explain语句，他并没有真正去执行sql，而是进行的估算。

相关推荐：

MySQL分页性能优化指南

php mysql分页类(php新手入门)

php+mysql分页代码详解_PHP教程

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!