You can think of indexes like mini-tables inside your tables. These mini-tables store sub-sets of information from your table that let the engine look things up without needing to scan every row in the table.
For instance, assume you have the following table.
CREATE TABLE IF NOT EXISTS `indexes` (
`id` int(11) UNSIGNED NOT NULL AUTO_INCREMENT,
`is_true` tinyint(1) NOT NULL,
PRIMARY KEY (`id`)
)
- CREATE TABLE IF NOT EXISTS `indexes` (
- `id` int(11) UNSIGNED NOT NULL AUTO_INCREMENT,
- `is_true` tinyint(1) NOT NULL,
- PRIMARY KEY (`id`)
- )
As the table sits right now, if you have 100 rows in the table and you want to return all of the rows where the is_true column is actually true, the engine would have to scan all 100 rows looking for rows where that value is true even if there are only 50 rows that the value is true.
Now, if you apply an INDEX on the is_true column like so,
ALTER TABLE `test`.`indexes` ADD INDEX ( `is_true` )
then one of these mini-tables is created that keeps track of which rows have which value for the is_true column.
If you explore phpMyAdmin you'll see something called "cardinality", which is an approximation of how many unique values there are for a certain index. In the case of this is_true column where it's a BOOLEAN with a total of 2 possible values, your cardinality should be 2 at the most.
With that index applied though, the engine will not have to scan all 100 rows in the table, it will be able to check the index and grab the 50 rows with a value of true right away because the index keeps track of where rows with each value in that column are.
--
I'm not sure of the search terms at the moment, but if you search for database/index related terms at Ozzu and limit the authors to bigwebmaster and camperjohn, you'll come across some interesting discussions about indexes.

--
As for your function, I'm not sure it will really accomplish anything. I don't see anywhere for column names to be specified.
Strong with this one, the sudo is.