I use MySql through C and this goes OK.
Is here a way to get execution duration of the query?
Similar to the way we get "num_rows" or other related data in "mysql result".
Or I have to measure the time difference between the begining and the end of the execution?
No, measure it yourself. The MySQL library doesn't do it automatically as this would be a resource drain — and an unfortunate one for those 99% of cases where we don't want the timings.
Related
Should a statement be reused as many time as possible or there's a limitation?
If there is a limitation, when is the right time to close it?
Is creating and closing statement a costly operation?
Creating and closing a statement doesn't really make sense. I believe what you mean is creating and closing a cursor. A cursor is a query that you iterate over the results of. Typically you see them in Stored Procedures and Functions in MySQL. Yes, they have a cost to open and close and you should iterate over the entire set.
Alternately you're talking about prepared statements such as you might create using the PDO library in PHP. In which case, you can use them as many times as possible and indeed you should, as this is more efficient.
Every time MySQL receives a statement, it translates that into its own internal logic and creates a query plan. Using prepared statements means it only has to do this once rather than every time you call it.
Finally, you might be trying to ask about a connection, rather than a statement. In which case, again, the answer is yes - you can (and should) use it as many time as you need as there's a significant performance impact of opening it. Though you don't want to keep it open longer than you need it because MySQL has a maximum number of connections it can open.
Hopefully one of those will answer your question.
I have some people that need to perform query on my Db,
this is mostly done by using workbench.
The pro of letting them querying directly the DB instead of providing them a service is that I don't need to set up a service anytime they need different data.
The cons and my worry is that they may launch (potentially) queries that may cause the mysql process to hang...
What's the way(is there some?) to limit the resource that a mysql user may occupy by querying? (I'm thinking something like configuring a short query timeout per user... or maybe there's something better.)
Essentially, no.
Some people have invented a "long query killer". It is a moderately simple script that repeatedly does SHOW PROCESSLIST an kills any query that has been running longer than N seconds.
my question is as follows:
Why if I do the same query two times in shell MySql get two very different response times (ie,
the first time and the second a much shorter time)?
and how can I do to prevent this from happening??
thank you very much in advance
This is most likely down to query and/or result caching. if you run a query once, MySQL stores the compiled version of that query, and also has the indexes stored in memory for those particular tables, so any subsequent queries are vastly faster than the original.
This could be due to 1.query caching is turned on or due to 2.the difference in performance states of the system in which it is being executed.
In query caching if you run a query once mysql stores the compiled version of the query and is fetched when called again . the time for compiling is not there in the repeated execution of the same query . query caching can be turned off but it is not a good idea
I have a rather complicated trigger and I'm afraid it's execution time is too long. How can I measure it?
A trigger is like every other sql query, with the difference that it can not be called explicitly. About measuring performance of sql query it really depends on your implementation, so a little more information will be useful.
With php, with some tool... how?
The simplest way(in the db) is to INSERT NOW in the beginning of the trigger and INSERT NOW at the end.
But time measurement(if this is what you asked) is not always the best choice to measure performance.
This is a good way to start - Using the New MySQL Query Profiler
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!