The situation I am having is the following. I have a transactions database table. I have both an incremental id for each transaction as well as a unique ID to use for front-end purposes. An example ID would be:
f8e3df-6af0a9-3e1d54-c2dbed86
As you can see it uses hex values and it's divided in a 6-6-6-8 characters, making a total of 29 characters including the dashes.
For some queries I need to do the following:
SELECT * FROM Transactions WHERE uuid='f8e3df-6af0a9-3e1d54-c2dbed86';
I have around 17,000 entries in the database and it weighs about 209 MB. When I do a query like this I profile it with phpmyadmin and the execution takes several seconds. An example of this:
As you can see it's literally a SELECT with one WHERE condition and no JOINS or other processing whatsoever.
Normally I would think this could be an index issue, but the field has the following specs:
I am using the basic DigitalOcean Managed MySQL with 1GB of RAM and 1 vCPU. I am considering upgrading the server, but I don't think this particular case should cause such a slow query.
Am I using the wrong type of index for this field or is this a memory problem?
Would there be a difference if I lower the type to VARCHAR(29)?
FULLTEXT indexes are only employed if you use the MATCH()...AGAINST()
predicate. You should read the documentation on how to use FULLTEXT indexes and searches: https://dev.mysql.com/doc/refman/8.0/en/fulltext-search.html
This is true regardless of the size of the table or the definition of your VARCHAR column. It doesn't matter if you change to VARCHAR(29).
For a comparison using =
, you need to define an index as the default type, which is BTREE for InnoDB tables. You don't have to specify BTREE as the type of index, because it's the default.