Even MySQL accept a decent set of SQL (standard) comands, do not implement in production any query before testing and checking twise the production server response time.
Do you get more than 0.1000 sec then you may try to optimise.
This becomes a real issue if there will be many queries from many users at the same time and, if the server is shared amoung many companies. For example in a hosting environment.
Here it is an example:
At this point (Aug, 08) SELECT DISTINCT produces significant time processing with MySQL versison 5.1x
If mix this command with a “JOIN” command and if a few users are applying this query on database , then the server may stop working properly.
Options to solve it:
- optimise the query – work around. Every case is special.
As a main point , consider that MySQL is a php based scripting so do not hesitate to make a “php approach” when you produce SQL statement.
- Go for postgreSQL, redesign a bit database and use fields of array type.
Doing this:
You take advantages of the power and stabilty of a “Oracle” style and behaviour database.
The number of tables will decrese.
Searching speed will increase significantly.
You will have a clean SQL code
____________
Do not upgrade from one version to a new one on production environment before having a backup plan.
Loading ...
(20 votes, average: 4.75 out of 5, rated)
