I have a very long query in MySQL (MariaDB) which runs multiple JOIN and LEFT JOIN to 5 or more tables (InnoDB). Is it better to convert this to a view instead?
A view is just a stored SQL, nothing more. It is going to be executed in the exact same way. It can, however, be convenient to be able to query one single object instead of writing messy join everywhere.
Views are an organizational tool, not a performance enhancement tool.
Also See:
Performance of VIEW vs. SQL statement
Related
I have a web app, which has quite a few queries being fired from every page. As more data was added to the DB, we noticed that the pages were taking longer and longer to load.
On examining PhpMyAdmin -> Status -> Joins, we noticed this (with the number in red):
Select_full_join 348.6 k The number of joins that do not use indexes. If this value is not 0, you should carefully check the indexes of your tables.
How do I determine which joins are causing the problems? Are all the joins equally to be blamed?
How do I determine which columns should be indexed, for the performance to be proper?
We are using CakePHP + MySQL, and the queries are all auto-generated.
The rule of thumb that I have always used, is that if I am using join, the fields that I am joining on need to be indexed.
For instance, if you have a query like the following:
SELECT t1.name, t2.salary
FROM employee AS t1
INNER JOIN info AS t2 ON t1.name = t2.name;
Both t1.name and t2.name should be indexed.
Below are some good reads for this as well:
Optimizing MySQL: Importance of JOIN Order
How to optimize MySQL JOIN queries through indexing
And in general, this guy's site has some good info as well.
MySQL Optimizer Team
Edit: This is always helpful.
And if you have access to your server settings, check out:
MySQL Slow Server Logs
Once you have a log of slow queries, you can use explain on them to see what needs indexing.
If you don't know which queries are running inefficiently, you have a couple of choices.
You could try this:
Try issuing the command SHOW FULL PROCESSLIST from phpmyadmin while your web site is active. It will show you, hopefully, a bunch of slow running queries. The FULL processlist should give you the entire query. You could then use the EXPLAIN command to figure out what it's doing.
You should also try this:
Think through the work your application is doing on behalf of your users. Think through which of your queries have to romp through lots of data to deliver value to the users. Think through which tables are growing as your application gets used more and more.
Then, find your queries that deliver that value, and that access your growing tables. Again, use the EXPLAIN command to see how MySQL is processing them, and add indexes as needed.
I suspect it will be very obvious which indexes you should add. Add the obvious ones, then let your system stabilize for a couple of workdays, then remeasure.
Notice that this is a normal part of bringing a new application into production.
Is it possible to create a view and make mysql use it internaly each time when join is required. The background of this question is I don't want to change the application which uses joins but want to speed up the queries
No, you can't say to mysql use view if some query uses joins.
For speeding up your queries you should:
Enable mysql slow query log.
Check each query from this one using explain.
Try to add indexes if it's necessary.
I want to create a query result page for a simple search, and i don't know , should i use views in my db, would it be better if i would write a query into my code with the same syntax like i would create my view.
What is the better solution for merging 7 tables, when i want to build a search module for my site witch has lots of users and pageloads?
(I'm searching in more tables at the same time)
you would be better off using a plain query with joins, instead of a view. VIEWS in MySQL are not optimized. be sure to have your tables properly indexed on the fields being used in the joins
If you always use all 7 tables, i think you should use views. Be aware that mysql changes your original query when creating the view so its always good practice to save your query elsewhere.
Also, remember you can tweak mysql's query cache env var so that it stores more data, therefore making your queries respond faster. However, I would suggest that you used some other method for caching like memcached. The paying version of mysql supports memcached natively, but Im sure you can implement it in the application layer no problem.
Good luck!
When using MySQL 5.1 Enterprise after years of using other database products like Sybase, Infomix, DB2; I run into things that MySQL just doesn't do. For example, it can only generate an EXPLAIN query plan for SELECT queries.
What other things I should watch out for?
You may take a look at long list here: MySQL Gotchas
Full outer joins. But you can still do a left outer join union right outer join.
One thing I ran into late in a project is that MySQL date types can't store milliseconds. Datetimes and timestamps only resolve to seconds! I can't remember the exact circumstances that this came up but I ended up needing to store an int that could be converted into a date (complete with milliseconds) in my code.
MySQL's JDBC drivers cache results by default, to the point that it will cause your program run out of memory (throw up OutOfMemory exceptions). You can turn it off, but you have to do it by passing some unusual parameters into the statement when you create it:
Statement sx = c.createStatement(java.sql.ResultSet.TYPE_FORWARD_ONLY,java.sql.ResultSet.CONCUR_READ_ONLY);
sx.setFetchSize(Integer.MIN_VALUE);
If you do that, the JDBC driver won't cache results in memory, and you can do huge queries BUT what if you're using an ORM system? You don't create the statements yourself, and therefore you can't turn of caching. Which basically means you're completely screwed if you're ORM system is trying to do something involving a lot of records.
If they had some sense, they would make that configurable by the JDBC URL. Oh well.
Allow for Roles or Groups
It doesn't cost a fortune. Try building a clustered website on multiple machines with multiple cores on an oracle database. ouch.
It still doesn't do CHECK constraints!
Is it possible to do a cross table join in mysql spaning different tables? in different databases.
This seem to be easily possible in MSSQL, and greatly speeds up data transfer?
How about mysql, do you need to use a powerful IDE to achieve this? or do you have to write a program to do something like this?
UPDATE tblUser
SET tblUser.ReceiveInfo=old_database.dbo.contact.third_party_info_yn
FROM tblUser inner join old_database.dbo.contact
ON old_database.dbo.contact.id=tblUser.oldid
Sure, very easy. Prefix the table name with the database name, like you show. We do cross-database joins on a regular basis. For example:
SELECT COUNT(*) FROM newusers1.users
JOIN newusers2.users
It certainly won't speed up data transfer compared to having both tables in the same database, though.
Now, if your tables are sitting on different database servers, the answer is no. An example of this is if your database is too big and you need to shard your tables. Things get more than a little messy. But given that you seem to be happy with the MS SQL solution, that does not seem to apply here.
In MySQL you can do cross DB joins and, by way of the FEDERATED engine, even cross server joins.
MySQL doesn't actually care if the tables are in the same "database", it's just a logical collection of tables for convenient administration, permissions etc.
So you can do a join between them just as easily as if they were in the same one (see ChrisInEdmonton's answer)