Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revision | |
| abap:perf [2016/04/28 15:30] – ginko | abap:perf [2016/06/21 17:23] (current) – [DB] ginko |
|---|
| * La DB limite la taille des contraintes ''IN'' dans les clauses ''WHERE'' (le traducteur SQL écrit en fait des contraintes classiques avec des identités ou des BETWEEN, qui peuvent être très (très) longues). En général cette limite est d'ordre du millier (dépend de la longueur du champ). | * La DB limite la taille des contraintes ''IN'' dans les clauses ''WHERE'' (le traducteur SQL écrit en fait des contraintes classiques avec des identités ou des BETWEEN, qui peuvent être très (très) longues). En général cette limite est d'ordre du millier (dépend de la longueur du champ). |
| * Sur une grosse requête, toujours mettre une contrainte sur au moins l'un des index de chaque table. | * Sur une grosse requête, toujours mettre une contrainte sur au moins l'un des index de chaque table. |
| | * Lors de la création des indexes, ne jamais oublier de mettre le champs ''MANDT''... le kernel a beau gérer le champs ''MANDT'' en scred assez souvent (''SELECT'', champs de jointure, etc), il reste des cas où il faut tout de même citer explicitement le champs (par exemple lors d'un ''INNER JOIN'', il faut sélectionner explicitement le champs mandant si on veut récupérer l'intégralité des champs de l'une des tables). |
| ===== itab ===== | ===== itab ===== |
| * Le ''LOOP AT .. WHERE'' passe par un optimiseur alors que pour le read table, ça doit être fait à la main avec le ''BINARY SEARCH''. | * Le ''LOOP AT .. WHERE'' passe par un optimiseur alors que pour le read table, ça doit être fait à la main avec le ''BINARY SEARCH''. |
