[TYPO3-dev] list module hangs at 1 million records

Franz Holzinger franz at fholzinger.com
Wed Jul 23 16:46:14 CEST 2008


Hello Ries,

ries van Twisk a écrit :

> So you problem is the sorting function that TYPO3 adds.
> 
> Since the cardinality is so low on your table, MySQL almost needs to do
> a full index scan to find the 20 records.
> And specially for sorting it needs to go through all 1 mil records.
> 
> First let's speed up using the sorting field. Do something like this:
> 
> update YOURLARGETABLE set sorting=uid;
> 
> That will create a unique entry for each sorting field based on the uid
> 
> Also do the same for crdate, but like this:
> update YOURLARGETABLE set crdate= 1216817772  + uid;
> 
> Then create two indexes. One on crdate and one on sorting.
> 
> Repeat these queries:
> 
> SELECT * FROM table WHERE pid=1 AND deleted=0 ORDER BY crdate LIMIT 21,20;

Affichage des enregistrements 0 - 19 (20 total, traitement: 8.3050 sec.)
requête SQL:
SELECT *
FROM `largetable`
WHERE pid =1
AND deleted =0
ORDER BY crdate DESC
LIMIT 21 , 20


> SELECT * FROM table WHERE pid=1 AND deleted=0 ORDER BY sorting LIMIT 21,20;

Affichage des enregistrements 0 - 19 (20 total, traitement: 7.4448 sec.)
requête SQL:
SELECT *
FROM `largetable`
WHERE pid =1
AND deleted =0
ORDER BY sorting
LIMIT 21 , 20

> What you should see is that the above two SQL's run a lot faster now.

It is about 7 seconds now instead of 31 seconds we had before. It has
got 4-5 times faster than before.

With EXPLAIN this gives:



id 	select_type 	table 	type 	possible_keys 	key 	key_len ref 	rows 	Extra
1 	SIMPLE 	tx_largetable 	range 	parent 	parent 	4  NULL 	1665224 	Using
where; Using filesort

It has only used the key 'parent', but it did not use the 2 additional
keys 'crdate' and 'sorting'.

Franz







More information about the TYPO3-dev mailing list