Re: help wit query optimization (cont'd)
On Jan 9, 2008 8:34 AM, Sebastian Mendel <[EMAIL PROTECTED]> wrote: > yes, as written in the mentioned article the test is only relevant with > correct used indexes, but MySQL does not use more than one index, so this > query cannot all be done with indexes Well, first of all, MySQL 5 does use more than one index, although I'm not sure it can do this with a full text index. http://dev.mysql.com/doc/refman/5.0/en/index-merge-optimization.html Also, there's a lot of room between a full table scan and using every index. Using any index in a way that allows the query to be satisfied without scanning every single row should be enough to make the count query better. - Perrin -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: help wit query optimization (cont'd)
Perrin Harkins schrieb: > On Jan 9, 2008 4:33 AM, Sebastian Mendel <[EMAIL PROTECTED]> wrote: >> usually ... but i do not know of any index capable of having FULLTEXT and >> 'normal' fields in one index > > Does that matter? yes, as written in the mentioned article the test is only relevant with correct used indexes, but MySQL does not use more than one index, so this query cannot all be done with indexes please correct me if i am wrong -- Sebastian -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: help wit query optimization (cont'd)
On Jan 9, 2008 4:33 AM, Sebastian Mendel <[EMAIL PROTECTED]> wrote: > usually ... but i do not know of any index capable of having FULLTEXT and > 'normal' fields in one index Does that matter? It would have to be doing a full scan for SQL_CALC_FOUND_ROWS to work out well. - Perrin -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: help wit query optimization (cont'd)
Perrin Harkins schrieb: > On Jan 4, 2008 5:51 PM, Eben <[EMAIL PROTECTED]> wrote: >> The resultset is paginated on the front end using the >> SQL_CALC_FOUND_ROWS functionality... > > Usually a bad idea: > http://www.mysqlperformanceblog.com/2007/08/28/to-sql_calc_found_rows-or-not-to-sql_calc_found_rows/ usually ... but i do not know of any index capable of having FULLTEXT and 'normal' fields in one index > WHERE MATCH table_2.field AGAINST ('value') > AND table_2.current = 1 > AND table_2.shared_id IN (SELECT shared_id FROM table_1_view) or am i wrong? -- Sebastian -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: help wit query optimization (cont'd)
I've never used this feature before on my application. On Jan 5, 2008 7:06 AM, Perrin Harkins <[EMAIL PROTECTED]> wrote: > On Jan 4, 2008 5:51 PM, Eben <[EMAIL PROTECTED]> wrote: > > The resultset is paginated on the front end using the > > SQL_CALC_FOUND_ROWS functionality... > > Usually a bad idea: > > http://www.mysqlperformanceblog.com/2007/08/28/to-sql_calc_found_rows-or-not-to-sql_calc_found_rows/ > > - Perrin > > -- > MySQL General Mailing List > For list archives: http://lists.mysql.com/mysql > To unsubscribe: > http://lists.mysql.com/[EMAIL PROTECTED] > > -- I'm a mysql DBA in china. More about me just visit here: http://yueliangdao0608.cublog.cn
Re: help wit query optimization (cont'd)
On Jan 4, 2008 5:51 PM, Eben <[EMAIL PROTECTED]> wrote: > The resultset is paginated on the front end using the > SQL_CALC_FOUND_ROWS functionality... Usually a bad idea: http://www.mysqlperformanceblog.com/2007/08/28/to-sql_calc_found_rows-or-not-to-sql_calc_found_rows/ - Perrin -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
help wit query optimization (cont'd)
I left something out, the query looks like: SELECT SQL_CALC_FOUND_ROWS table_1.id,table_2.* FROM table_2 LEFT JOIN table_1 ON table_2.shared_id = table_1.shared_id WHERE MATCH table_2.field AGAINST ('value') AND table_2.current = 1 AND table_2.shared_id IN (SELECT shared_id FROM table_1_view) LIMIT 0,10 The resultset is paginated on the front end using the SQL_CALC_FOUND_ROWS functionality... thanks, Eben -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]