Hello Mark,
Thanks for your short response. I have checked it again. I have
restarted MySQL first. When I executed command
select SQL_CALC_FOUND_ROWS
BF_USER.LOGIN_NAME,
BF_USER.EMAIL,
BF_USER.ID,
BF_USER.MODIFICATION_DATE,
BF_USER.SUPER_USER,
BF_USER.GUEST_ACCESS_ENABLED,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Juleni wrote:
> Hello Brent,
>
>Thanks for your answer, I have try to use clause SQL_CALC_FOUND_ROWS
> within my SELECT query (and I also didn't use SELECT COUNT(*) ... query).
>But when I used SQL_CALC_FOUND_ROWS and then I retrieved number o
Hello Brent,
Thanks for your answer, I have try to use clause SQL_CALC_FOUND_ROWS
within my SELECT query (and I also didn't use SELECT COUNT(*) ... query).
But when I used SQL_CALC_FOUND_ROWS and then I retrieved number of
all columns using SELECT FOUND_ROWS(), the performance was worse than
First you are using two distinct queries where you should be using two
"related". Specifically, add SQL_CALC_FOUND_ROWS to your first query
that retrieves data, then issue a query to see how many rows you would
have had if you hadn't specified a LIMIT:
SELECT FOUND_ROWS()
The second query sh
Hello,
I have a problem with poor performance when I execute select
from 50.000 records. I have a test that retrieve page by page
(20 records per page) all data from a table. It means I'm executing
2500 selects in the cycle for retrieving each page and I'm retrieving
also time duration of some o
