> # Query_time: 17 Lock_time: 6 Rows_sent: 207550 > Rows_examined: 207550 > SELECT ID FROM sys_users;
If this is really the query that you want to do, there really isn't much you can optimize. You're asking for every ID in the table, so MySQL has to examine every row, and send every row. You can try to eliminate the lock time, though. Your query spent 6 seconds waiting for a read lock, so there was some other query updating the table. To avoid this, you can use InnoDB tables which use concurrency locking, so you can still read the rows even if somebody else is trying to update them. > I'd like to optimize this. 17 seconds is too much. How do you > guys judge > the actual CPU impact of the process that is sending 207550 > rows back to > the query originator? Can it be neglected - and should we rather > optimize the query itself, that is the process of examining the rows. It's not the CPU impact, but the data transfer impact. You're moving 207550 integers, or about 800KB of data. If you really need all that data, you're going to have to wait for it to be transferred. > > In other words: > > Should we try to make Rows_examined: a value like 1000 or so. > Or can we > keep it like this and rather fix Rows_sent to e.g.: 1000. You probably don't really need all the ID numbers in the table. What you should do is figure out which rows you really want, and select them out of the table, rather than selecting all the rows and then processing them somehow on the client side. > > Thanks, > Markus --------------------------------------------------------------------- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
