Tried to do some researching and always ends up with
select concat(round(sum(DATA_LENGTH/1024/1024),2),'MB') as data
FROM TABLES WHERE table_schema='home';
which shows the total size that has already been used, is there any command that I can use to see the total disk space(capacity of the server)?
This question has been answered [around four years ago][1].
To sum up the answer, run this command:
mysql> select table_schema, sum((data_length+index_length)/1024/1024) AS MB from information_schema.tables group by 1;
+--------------------+-----------------+
| table_schema | MB |
+--------------------+-----------------+
| prod | 298025.72448921 |
| information_schema | 0.00781248 |
| maatkit | 70.77330779 |
| mysql | 0.66873168 |
| test | 4752.31449127 |
+--------------------+-----------------+
5 rows in set (0.01 sec)
If you have a very large number of tables, it can be slow, as you have
already discovered.
Hope this is helpful.
The total disk space available to MySQL is the total space remaining on that disk partition. You can check that with the df command. The MySQL database is often in /var/lib/db but you'll have to check your configuration to be sure.
If you're on a hosted server, you might also have a disk quota. How to check that depends on your hosting service.
Related
I have recently started seeing high amount of set-option query count in mysql. Its around 15k/sec
mysql> SHOW GLOBAL STATUS LIKE '%set%';
+-------------------+------------+
| Variable_name | Value |
+-------------------+------------+
| Com_reset | 0 |
| Com_set_option | 5472249432 |
| Com_show_charsets | 31 |
| Com_stmt_reset | 0 |
+-------------------+------------+
4 rows in set (0.00 sec)
However nothing like "set" operation is seen in the "show processlist"
IMAGE
Any idea why?
Thanks
COM_SET_OPTION count is high probably because the MySQL library you are using issues a SET option command every time it creates a connection to the MySql server. Few libraries tend to set some basic options everytime they create a new connection.
This could also happen if your system does a lot of transactions with MySQL.
However, this is pretty normal. I am using MySql 5.6.34 with PHP. Refer
With administrative permissions im mysql, how can I see all the open connections to a specific db in my server?
The command is
SHOW PROCESSLIST
Unfortunately, it has no narrowing parameters. If you need them you can do it from the command line:
mysqladmin processlist | grep database-name
As well you can use:
mysql> show status like '%onn%';
+--------------------------+-------+
| Variable_name | Value |
+--------------------------+-------+
| Aborted_connects | 0 |
| Connections | 303 |
| Max_used_connections | 127 |
| Ssl_client_connects | 0 |
| Ssl_connect_renegotiates | 0 |
| Ssl_finished_connects | 0 |
| Threads_connected | 127 |
+--------------------------+-------+
7 rows in set (0.01 sec)
Feel free to use
Mysql-server-status-variables or Too-many-connections-problem
That should do the trick for the newest MySQL versions:
SELECT * FROM INFORMATION_SCHEMA.PROCESSLIST WHERE DB like "%DBName%";
You can invoke MySQL show status command
show status like 'Conn%';
For more info read Show open database connections
SQL:
show full processlist;
This is what the MySQL Workbench does.
In MySql,the following query shall show the total number of open connections:
show status like 'Threads_connected';
If you're running a *nix system, also consider mytop.
To limit the results to one database, press "d" when it's running then type in the database name.
From the monitoring context here is how you can easily view the connections to all databases sorted by database. With that data easily monitor.
SELECT DB,USER,HOST,STATE FROM INFORMATION_SCHEMA.PROCESSLIST ORDER BY DB DESC;
+------+-------+---------------------+-----------+
| DB | USER | HOST | STATE |
+------+-------+---------------------+-----------+
| web | tommy | 201.29.120.10:41146 | executing |
+------+-------+---------------------+-----------+
If we encounter any hosts hots max connections and then not able to connect, then we can reset host tables by flushing it and is as follows:
FLUSH HOSTS;
In query browser right click on database and select processlist
My debian-based is booting so slow after I installed MySQL and imported some databases on it. Looking for some statement, I found this one during boot:
mysql> show full processlist;
+----+------------------+-----------+------+---------+------+----------------+----------------------------------------------------------------------+
| Id | User | Host | db | Command | Time | State | Info |
+----+------------------+-----------+------+---------+------+----------------+----------------------------------------------------------------------+
| 9 | debian-sys-maint | localhost | NULL | Query | 12 | Opening tables | select count(*) into #discard from `information_schema`.`PARTITIONS` |
| 10 | root | localhost | NULL | Query | 0 | NULL | show full processlist |
+----+------------------+-----------+------+---------+------+----------------+----------------------------------------------------------------------+
2 rows in set (0.00 sec)
Here the statement that causing trouble:
select count(*) into #discard from `information_schema`.`PARTITIONS`
I have +-10 databases totaling over 8gb of data.
Is there any configuration to disable this query on system booting ? If yes, why run it during boot ?
Information
I have a standard MySQL installation without custom configs.
Best regards.
It seems Debian, whose Linux Mint is based upon, have scripts that get executed when the mysql server is started or restarted, to check for corrupted tables and make an alert for that.
In my Debian server, the culprit seems to be /etc/mysql/debian-start bash script, which in turn calls /usr/share/mysql/debian-start.inc.sh , so check both scripts and comment out the function that is iterating all your tables, from a quick look it seems the following:
check_for_crashed_tables;
which is called from the debian-start script I mentioned above.
I have problem related to mysql database. i am linux webserver admin and i am facing a problem with a mysql query. The database is very small. I tried to track in logs and found that a query is taking minimum 5 sec to respond . The first page of site is coming from the database. Client are using cms. when the server gets some number of hits database server starts to give response very slowly and wait time increases from 5 sec to several seconds.
I checked slow query logs
{
Query_time: 11.480138 Lock_time: 0.003837 Rows_sent: 921 Rows_examined: 3333
SET timestamp=1346656767;
SELECT `Tender`.`id`,
`Tender`.`department_id`,
`Tender`.`title_english`,
`Tender`.`content_english`,
`Tender`.`title_hindi`,
`Tender`.`content_hindi`,
`Tender`.`file_name`,
`Tender`.`start_publish`,
`Tender`.`end_publish`,
`Tender`.`publish`,
`Tender`.`status`,
`Tender`.`createdBy`,
`Tender`.`created`,
`Tender`.`modifyBy`,
`Tender`.`modified`
FROM `mcms_tenders` AS `Tender`
WHERE `Tender`.`department_id` IN ( 31, 33, 32, 30 );
}
Every line in the log is same only there is diff in Query time.
Is there any way tweak the performance?
Update: Here is the EXPLAIN result:
+----+-------------+--------+------+---------------+------+---------+------+------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+--------+------+---------------+------+---------+------+------+-------------+
| 1 | SIMPLE | Tender | ALL | NULL | NULL | NULL | NULL | 3542 | Using where |
+----+-------------+--------+------+---------------+------+---------+------+------+-------------+
1 row in set, 1 warning (0.00 sec)
client is saying they are using Index so i run the command to check the indexing.
I got following output. Does It means they are using Indexing.
+--------------+------------+----------+--------------+-------------+-----------+------------+----------+--------+------+------------+---------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment |
+--------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
| mcms_tenders | 0 | PRIMARY | 1 | id | A | 4264 | NULL | NULL | | BTREE | |
+--------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
The normal way to tweak the performance of a query like this is to create an index on department_id.
However, this assumes that Tenders is actually a table and not a view. You should confirm this, since the problem may be in a view.
Also, from what you describe the issue may be the connection from the server to the end users. I would try running the query locally on the server (or checking the execute time strictly on the server) to see if the query is really taking that long.
"when the server gets some number of hits"
Define 'some number'. It makes sense that reading the database is slower when it is more heavily used. Also, MySQL has a query cache that is fully invalidated when changes are made to the data. So every time someone inserts, deletes or modifies a record in this table, the next queries will be slower because the table date is still uncached.
But 11 seconds for a query like this is very slow, so either the load is way too high, the hardware insufficient or broken or your database lacks indexes (I always forget to mention that at first, because I assume adding indexes to be a second nature for anyone working with databases).
I'm working through some optimization work, and I've noticed that in some mysql dumps people post in articles and questions (which I cannot find again now that I'm actually looking), there are high-precision execution times (0.05985215 sec instead of 0.06 sec).
How can I see these more precise times for my queries on the command line?
EDIT
Example of this is:
+----------+
| COUNT(*) |
+----------+
| 11596 |
+----------+
1 row in set (0.05894344 sec)
Using profiling gets me part of the way there, but produces an output too long, and I have to remember to enable it. I am just looking for a simple high-precision duration.
SET profiling = 1;
<query>
SHOW PROFILES;
Gives me something like this:
+----------------------+-----------+
| Status | Duration |
+----------------------+-----------+
| (initialization) | 0.000005 |
| checking permissions | 0.00001 |
| Opening tables | 0.000499 |
| Table lock | 0.000071 |
| preparing | 0.000018 |
| Creating tmp table | 0.00002 |
| executing | 0.000006 |
| Copying to tmp table | 6.565327 |
| Sorting result | 0.000431 |
| Sending data | 0.006204 |
| query end | 0.000007 |
| freeing items | 0.000028 |
| closing tables | 0.000015 |
| logging slow query | 0.000005 |
+----------------------+-----------+
14 rows in set (0.00 sec)
It seems that the best answer to this is to enable profiling. There have been no other leads that pan out.
Best answer, use query profiling.
SET profiling = 1;
<query>
SHOW PROFILES;
this question is best answered by looking at the source of the mysql command line client. the relevant piece of code,
static void nice_time(double sec,char *buff,bool part_second)
{
// ...
if (part_second)
sprintf(buff,"%.2f sec",sec);
else
sprintf(buff,"%d sec",(int) sec);
}
has the number of digits after the decimal point for the sec value hard-coded into (2). this would make me conclude that higher precision times are not possible with a stock mysql install.
of course, you could patch this code, make it configurable, etc, and install from source. i guess this is what the people in the articles and questions you mentioned are doing. your best chance to find out is to just ask them (see my comment to your question).
Without seeing the dumps you're talking about, it's probably a user defined function? See this thread ( http://lists.mysql.com/internals/33707 ) for a couple of gotchas and how to do it.
Not elegant, but working solution is to patch /usr/bin/mysql:
# copy the original mysql binary to your home dir
cp /usr/bin/mysql ~/mysql
# patch it
sed -i -e 's/%.2f sec/%.8f sec/1' ~/mysql
# run it from the home directory
~/mysql
It works because CURRENTLY there is only one format string '%.2f sec' in the mysql binary, BUT it may change over time.
You may revert to the original binary by applying reverse patch:
sed -i -e 's/%.8f sec/%.2f sec/1' ~/mysql