The previous example selected specific columns from the birds table and limited the results with the LIMIT clause. However, the rows were listed in whatever order they were found in the table. We’ve decided to see only a tiny subset of the birds in the Charadriidae family, so ordering can make a difference. If we want to put the results in alphabetical order based on the values of the common_name column, we add an ORDER BY clause like this:
SELECT common_name, scientific_name FROM birds WHERE family_id = 103 ORDER BY common_name
LIMIT 3;
+---+---+
| common_name | scientific_name | +---+---+
| Black-bellied Plover | Pluvialis squatarola |
| Mountain Plover | Charadrius montanus |
| Pacific Golden Plover | Pluvialis fulva | +---+---+
Notice that the ORDER BY clause is located after the WHERE clause and before the LIMIT clause. Not only will this statement display the rows in order by common_name, but it will retrieve only the first three rows based on the ordering. That is to say, MySQL will first retrieve all of the rows based on the WHERE clause, store those results in a temporary table behind the scenes, order the data based on the ORDER BY clause, and then return to the mysql client the first three rows found in that temporary table based on the LIMIT clause.
This activity is the reason for the positioning of each clause.
By default, the ORDER BY clause uses ascending order, which means from A to Z for an alphabetic column. If you want to display data in descending order, add the DESC option, as in ORDER BY DESC. There’s also a contrasting ASC option, but you probably won’t need to use it because ascending order is the default.
To order by more than one column, give all the columns in the ORDER BY clause in a comma-separated list. Each column can be sorted in ascending or descending order. The clause sorts all the data by the first column you specify, and then within that order by the second column, etc. To illustrate this, we’ll select another column from the birds table,
family_id, and we’ll get birds from a few more families. We’ll select some other types of shore birds: Oystercatchers (i.e., Haematopodidae), Stilts (e.g., Recurvirostridae), and Sandpipers (e.g., Scolopacidae). First, we need the family_id for each of these families.
Execute the following on your server:
SELECT * FROM bird_families WHERE scientific_name
IN('Charadriidae','Haematopodidae','Recurvirostridae','Scolopacidae');
+---+---+---+---+
| family_id | scientific_name | brief_description | order_id | +---+---+---+---+
| 103 | Charadriidae | Plovers, Dotterels, Lapwings | 102 |
| 160 | Haematopodidae | Oystercatchers | 102 |
| 162 | Recurvirostridae | Stilts and Avocets | 102 |
| 164 | Scolopacidae | Sandpipers and Allies | 102 | +---+---+---+---+
In this SELECT statement, we added another item to the WHERE clause, the IN operator. It lists, within parentheses, the various values we want in the scientific_name column.
Let’s use the IN operator again to get a list of birds and also test the LIMIT clause:
SELECT common_name, scientific_name, family_id FROM birds
WHERE family_id IN(103, 160, 162, 164) ORDER BY common_name
LIMIT 3;
+---+---+---+
| common_name | scientific_name | family_id | +---+---+---+
| | Charadrius obscurus aquilonius | 103 |
| | Numenius phaeopus phaeopus | 164 |
| | Tringa totanus eurhinus | 164 | +---+---+---+
Notice that we didn’t put the numeric values in quotes as we did with the family names in the previous SQL statement. Single or double quotes are necessary for strings, but they’re optional for numeric values. However, it’s a better practice to not use quotes around numeric values. They can affect performance and cause incorrect results if you mix them with strings.
There is one odd thing about the results here: there aren’t any common names for the birds returned. That’s not a mistake. About 10,000 birds in the birds table are true species of birds, and about 20,000 are subspecies. Many subspecies don’t have a unique common name. With about 30,000 species and subspecies of birds, with all of the minor nuances between the subspecies bird families, there just aren’t common names for all of them.
Each bird has a scientific name assigned by ornithologists, but everyday people who use the common names for birds don’t see the subtle distinctions that ornithologists see. This is why the scientific_name column is necessary and why the common_name column cannot be a key column in the table.
Let’s execute that SQL statement again, but add another factor to the WHERE clause to show only birds with a value for the common_name column:
SELECT common_name, scientific_name, family_id FROM birds
WHERE family_id IN(103, 160, 162, 164) AND common_name != ''
ORDER BY common_name LIMIT 3;
+---+---+---+
| common_name | scientific_name | family_id | +---+---+---+
| African Oystercatcher | Haematopus moquini | 160 |
| African Snipe | Gallinago nigripennis | 164 |
| Amami Woodcock | Scolopax mira | 164 | +---+---+---+
In the WHERE clause, we added the AND logical operator to specify a second filter. For a row to match the WHERE clause, the family_id must be one in the list given and the
common_name must not be equal to a blank value.
Nonprogrammers will have to learn a few conventions to use large WHERE clauses. We’ve seen that an equals sign says, “The column must contain this value,” but the != construct says, “The column must not contain this value.” And in our statement, we used '' to refer to an empty string. So we’ll get the rows where the common name exists.
In this case, we couldn’t ask for non-NULL columns. We could have set up the table so that birds without common names had NULL in the common_name column, but we chose to
instead use empty strings. That’s totally different in meaning: NULL means there is no value, whereas the empty string is still a string even if there are no characters in it. We could have used NULL, but having chosen the empty string, we must use the right value in our WHERE clause.
Incidentally, != is the same as <> (i.e., less-than sign followed by greater-than sign).