If you have read any of my blog posts, chances are you have seen many times where I have mentioned that typically there are multiple ways to achieve needed outcomes and results in SQL.
Maybe you need a total count of rows returned from a particular query’s results set? There are a myriad number of means to get that result.
However, it just so happens MySQL has a function that will determine the count of rows and return it (the number) for you. Honestly, I was not aware of it until a reader brought it to my attention.
What do I do? Dive right in and learn about it.
You may as well join me…
This will be the last blog post for Digital Owl’s Prose in 2018. The next post will be in the second week of January 2019. No matter where you are in the world, whether you celebrate or not, I wish you and yours a terrific holiday season. I truly hope 2018 was all you wanted it to be, with 2019 to be that and much more. Happy Holidays!!!
Photo by Siora Photography on Unsplash
Note: All data, names or naming found within the database presented in this post, are strictly used for practice, learning, instruction, and testing purposes. It by no means depicts actual data belonging to or being used by any party or organization.
OS and DB used:
- Xubuntu Linux 16.04.5 LTS (Xenial Xerus)
- MySQL 5.7.24
I am using the practice Sakila database for this blog post.
Below, we have the actor table description:
1 2 3 4 5 6 7 8 9 10 | mysql> DESC actor; +-------------+----------------------+------+-----+-------------------+-----------------------------+ | Field | Type | Null| Key | Default | Extra | +-------------+----------------------+------+-----+-------------------+-----------------------------+ | actor_id | smallint(5) unsigned | NO | PRI | NULL | auto_increment | | first_name | varchar(45) | NO | | NULL | | | last_name | varchar(45) | NO | MUL | NULL | | | last_update | timestamp | NO | | CURRENT_TIMESTAMP | on update CURRENT_TIMESTAMP | +-------------+----------------------+------+-----+-------------------+-----------------------------+ 4 rows in set (0.00 sec) |
In this first example, I am querying for those actors whose last name starts with an ‘A’.
However, I only want 4 rows returned in the results set; easily handled using the LIMIT clause.
Additionally, I need to determine how many total rows exist in the table for the same WHERE condition. In other words, all rows that would be returned in the query results had I not constrained them via LIMIT.
Needy much aren’t I?
Of course, I can retrieve those results, using 2 separate queries, but MySQL has a handy Information Function named FOUND_ROWS() that is ‘tailor-made’ for this kind of requirement.
There are two versions I will demonstrate here, each different from the other, dependent upon including (or not) a SQL_CALC_FOUND_ROWS option, as part of the the query.
This query uses that option:
1 2 3 4 5 6 7 8 9 10 11 12 13 | mysql> SELECT SQL_CALC_FOUND_ROWS * -> FROM actor -> WHERE last_name LIKE 'A%' -> LIMIT 4; +----------+------------+-----------+---------------------+ | actor_id | first_name | last_name | last_update | +----------+------------+-----------+---------------------+ | 58 | CHRISTIAN | AKROYD | 2006-02-15 04:34:33 | | 92 | KIRSTEN | AKROYD | 2006-02-15 04:34:33 | | 182 | DEBBIE | AKROYD | 2006-02-15 04:34:33 | | 118 | CUBA | ALLEN | 2006-02-15 04:34:33 | +----------+------------+-----------+---------------------+ 4 rows in set (0.01 sec) |
Now, the FOUND_ROWS() function will return the count for all rows that would have been returned from that previous query had the LIMIT clause not been used.
1 2 3 4 5 6 7 | mysql> SELECT FOUND_ROWS(); +--------------+ | FOUND_ROWS() | +--------------+ | 7 | +--------------+ 1 row in set (0.00 sec) |
Seven records are reported from the function call.
Is that correct?
By removing the LIMIT clause, any remaining records that pass the WHERE clause boolean conditional, are shown in the query results below:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | mysql> SELECT * -> FROM actor -> WHERE last_name LIKE 'A%'; +----------+------------+-----------+---------------------+ | actor_id | first_name | last_name | last_update | +----------+------------+-----------+---------------------+ | 58 | CHRISTIAN | AKROYD | 2006-02-15 04:34:33 | | 92 | KIRSTEN | AKROYD | 2006-02-15 04:34:33 | | 182 | DEBBIE | AKROYD | 2006-02-15 04:34:33 | | 118 | CUBA | ALLEN | 2006-02-15 04:34:33 | | 145 | KIM | ALLEN | 2006-02-15 04:34:33 | | 194 | MERYL | ALLEN | 2006-02-15 04:34:33 | | 76 | ANGELINA | ASTAIRE | 2006-02-15 04:34:33 | +----------+------------+-----------+---------------------+ 7 rows in set (0.00 sec) |
Seven is the correct number of rows according to the query results above.
What is FOUND_ROWS() characteristic’s without the SQL_CALC_FOUND_ROWS option?
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | mysql> SELECT * -> FROM actor -> WHERE last_name LIKE 'B%' -> LIMIT 6; +----------+------------+-----------+---------------------+ | actor_id | first_name | last_name | last_update | +----------+------------+-----------+---------------------+ | 112 | RUSSELL | BACALL | 2006-02-15 04:34:33 | | 67 | JESSICA | BAILEY | 2006-02-15 04:34:33 | | 190 | AUDREY | BAILEY | 2006-02-15 04:34:33 | | 115 | HARRISON | BALE | 2006-02-15 04:34:33 | | 187 | RENEE | BALL | 2006-02-15 04:34:33 | | 47 | JULIA | BARRYMORE | 2006-02-15 04:34:33 | +----------+------------+-----------+---------------------+ 6 rows in set (0.01 sec) |
1 2 3 4 5 6 7 | mysql> SELECT FOUND_ROWS(); +--------------+ | FOUND_ROWS() | +--------------+ | 6 | +--------------+ 1 row in set (0.00 sec) |
But, how many total records are part of that query results set, barring the LIMIT clause?
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 | mysql> SELECT * -> FROM actor -> WHERE last_name LIKE 'B%'; +----------+-------------+-----------+---------------------+ | actor_id | first_name | last_name | last_update | +----------+-------------+-----------+---------------------+ | 112 | RUSSELL | BACALL | 2006-02-15 04:34:33 | | 67 | JESSICA | BAILEY | 2006-02-15 04:34:33 | | 190 | AUDREY | BAILEY | 2006-02-15 04:34:33 | | 115 | HARRISON | BALE | 2006-02-15 04:34:33 | | 187 | RENEE | BALL | 2006-02-15 04:34:33 | | 47 | JULIA | BARRYMORE | 2006-02-15 04:34:33 | | 158 | VIVIEN | BASINGER | 2006-02-15 04:34:33 | | 124 | SCARLETT | BENING | 2006-02-15 04:34:33 | | 174 | MICHAEL | BENING | 2006-02-15 04:34:33 | | 14 | VIVIEN | BERGEN | 2006-02-15 04:34:33 | | 121 | LIZA | BERGMAN | 2006-02-15 04:34:33 | | 12 | KARL | BERRY | 2006-02-15 04:34:33 | | 60 | HENRY | BERRY | 2006-02-15 04:34:33 | | 91 | CHRISTOPHER | BERRY | 2006-02-15 04:34:33 | | 189 | CUBA | BIRCH | 2006-02-15 04:34:33 | | 25 | KEVIN | BLOOM | 2006-02-15 04:34:33 | | 37 | VAL | BOLGER | 2006-02-15 04:34:33 | | 185 | MICHAEL | BOLGER | 2006-02-15 04:34:33 | | 98 | CHRIS | BRIDGES | 2006-02-15 04:34:33 | | 39 | GOLDIE | BRODY | 2006-02-15 04:34:33 | | 159 | LAURA | BRODY | 2006-02-15 04:34:33 | | 167 | LAURENCE | BULLOCK | 2006-02-15 04:34:33 | +----------+-------------+-----------+---------------------+ 22 rows in set (0.00 sec) |
From this example we can see that since the SQL_CALC_FOUND_ROWS option is not present, FOUND_ROWS() reported the same number of rows that were returned in the query results using the LIMIT clause.
Using FOUND_ROWS() is super handy, but there is a ‘catch’ in what constitutes as ‘query results’. The number of rows found for the previous query can be indicative of a query involving a call to its (FOUND_ROWS()) previous self. Confused? Me too!
Let’s solidify this with an example query as below:
1 2 3 4 | mysql> SELECT * -> FROM actor -> WHERE last_name LIKE 'E%'; Empty set (0.00 sec) |
No results are returned from that query and FOUND_ROWS() reports 0 (zero) rows:
1 2 3 4 5 6 7 | mysql> SELECT FOUND_ROWS(); +--------------+ | FOUND_ROWS() | +--------------+ | 0 | +--------------+ 1 row in set (0.00 sec) |
Yet, another call to FOUND_ROWS():
1 2 3 4 5 6 7 | mysql> SELECT FOUND_ROWS(); +--------------+ | FOUND_ROWS() | +--------------+ | 1 | +--------------+ 1 row in set (0.00 sec) |
Based on my interpretation and understanding, the first call of SELECT FOUND_ROWS() returned one row for its query result, reporting that there are 0 (zero) rows returned from the original query filtering for actors with a last name that starts with E.
The subsequent call to SELECT FOUND_ROWS() returns a row reporting that there is a count of 1 row from the previous query – which had a count of 0 (zero) and was itself, a call to SELECT FOUND_ROWS().
If my assumption is incorrect (or skewed), please provide any correction(s) and explanation(s) in the comments below and many thanks in advance for any feedback!
Why is FOUND_ROWS() useful?
Although not necessarily demonstrated here, you may have a query that is quite expensive in terms of execution time.
Suppose the example data set used here, contained ~100000 rows. Instead of running the actual query without the LIMIT clause (for simplicity’s sake, this is not an ‘expensive’ query; so bear with me), you could use FOUND_ROWS().
Of course, retrieving a count of rows with the COUNT() function is always an option. Which brings me to the next point.
Several blog posts back (at the time of this writing), a reader provided fantastic feedback, information, corrections, and suggestions in regards to this blog post I wrote:
MySQL Stored Procedures: Create functions with error handling for repetitive tasks.
One suggestion was to use FOUND_ROWS() in my Stored Function verses a SELECT COUNT(*) INTO @some_variable type of syntax.
With that being said, in a follow-up blog post I will prototype and update that function as I continue to explore FOUND_ROWS(), putting it to ‘real-world’ use, so be sure and visit that post when it is published.
Like what you have read? See anything incorrect? Please comment below and I appreciate your reading and feedback!!!
Explore the official MySQL 5.7 Online Manual for more information.
A Call To Action!
Thank you for taking the time to read this post. I truly hope you discovered something interesting and enlightening. Please share your findings here, with someone else you know who would get the same value out of it as well.
Visit the Portfolio-Projects page to see blog post/technical writing I have completed for clients.
Have I mentioned how much I love a cup of coffee?!?!
To receive email notifications (Never Spam) from this blog (“Digital Owl’s Prose”) for the latest blog posts as they are published, please subscribe (of your own volition) by clicking the ‘Click To Subscribe!’ button in the sidebar on the homepage! (Feel free at any time to review the Digital Owl’s Prose Privacy Policy Page for any questions you may have about: email updates, opt-in, opt-out, contact forms, etc…)
Be sure and visit the “Best Of” page for a collection of my best blog posts.
Josh Otwell has a passion to study and grow as a SQL Developer and blogger. Other favorite activities find him with his nose buried in a good book, article, or the Linux command line. Among those, he shares a love of tabletop RPG games, reading fantasy novels, and spending time with his wife and two daughters.
Disclaimer: The examples presented in this post are hypothetical ideas of how to achieve similar types of results. They are not the utmost best solution(s). The majority, if not all, of the examples provided, are performed on a personal development/learning workstation-environment and should not be considered production quality or ready. Your particular goals and needs may vary. Use those practices that best benefit your needs and goals. Opinions are my own.
I get a warning using FOUND_ROWS() and SQL_CALC_FOUND_ROWS(). It says they will be deprecated in a future release. Am using MySQL 8.0.29. It also tells me to use COUNT(*) instead. Problem is, I get weird errors at times using this. Any other workarounds sir?
That’s the first I’ve heard about the depreciation warnings. What weird errors do you get with COUNT(*)?
Hi. Thanks for your reply. I have been using MySQL 5.x for the longest time. I have also been using Visual Foxpro 9.0 even longer. Haha. In my framework, I have use a class method that gets stats like rowcount using select count(*) …… ever since.
When I moved to MySQL 8.0.29, it displays this error:
Connectivity error: [MySQL][ODBC 8.0(w) Driver][mysqld-8.0.30] The number of attributes is larger than the number of attribute values provided
Hence, I sought to find alternative solutions. So I found your blog post using FOUND_ROWS() and SQL_CALC_FOUND_ROWS(). Upon further research, it was announced by MySQL that these two will be deprecated in a future release. If you try them at the new versions, it will show a warning about it.
Thank you for sharing this information with me in this comment for I wasn’t aware of it.