Home/ Questions/Q 8145219
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-06T13:35:39+00:00

I have three or four tables in a MySQL database associated with an upcoming

  • 0

I have three or four tables in a MySQL database associated with an upcoming Android app that potentially may explode to thousands of rows very fast. At this time, I have about 6 – 8 SELECT and 2 INSERT SQL commands that will need to be done.

After doing research, I have found that I will have to use indexing to cut down on load time. I have searched for several tutorials on different sites to see if I can pick this up — but I have found nothing that explains very clearly what and how to to do this.

Here’s the situation:

First and foremast, it will be using a Godaddy MySQL server. Unlimited bandwidth and 150,000 MB. Here is one table that will be getting lots of use:

items_id (int 11)
item (100 varchar) 
cat_id (int 11)

In PHPMyAdmin it says for indexes:

Keyname/PRIMARY  type/PRIMARY        Cardinality/576    items_id

So it appears there is an index established, correct?

Here is one SQL Query (via PHP) related to this table (SELECT):

 "SELECT * FROM items WHERE cat_id = ' ".$_REQUEST['category_id']."' ORDER BY TRIM(LEADING 'The ' FROM item) ASC;"

And another (INSERT):

 "INSERT INTO items (item, cat_id) VALUES ('{$newItem}', '{$cat_id}')"

My main questions are: With these methods, am I utilizing the best speed possible and making use of the established indexes? Or does this have “slow” written all over it?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Simple selects / inserts cannot be changed to take advantage of indexes.

    But indexes can be added to the tables to make the queries run faster.

    Well actually inserts don’t do anything with indexes unless you’re using InnoDB as a storage engine and foreign key constraints.

    If you’re using a column in the where / group by / order by clauses of a select statement you may consider adding an index on it. A good ideea would be to use EXPLAIN on the queries in cause and see how the database engine uses the columns in the where clause.

    If a column has a small set of non-unique possible values (gender: male/ female) it makes little sense to add an index for it because you won’t be searching for all the females or all the males (and half a table search is not very different than a full table search). But if you use that column along with another column to filter / group / sort you may want to add a composite index (multi-column index) on them.

    Databases within MySQL are organized as folders. The folders contain multiple files for each table.

    There’s a table definition file, a table data file and some index files. If you define an index for a column or multiple columns, a file for that index will be created.

    If you don’t have any indexes not even the primary key, any Select statement is going to do a full table search which for hundreds of thousands of entries becomes noticeably slow.

    If you define an index it will read all the unique values in the table for that column or set of columns and write a file that lists correspondences between a certain value of that column or those columns and the records that contain it.

    That file should be much smaller that the data file and should usually fit into memory entirely along side other index files. MySQL now has to intersect the matching record lists in that file to find out which records match the select criteria and then cherry-pick the data it needs from the data table.

    Primary and Unique indexes have a direct correspondence between one value and one record. So searching by unique value is fast.

    • 0