MySQL при работе с таблицами использует хорошо масштабируемые алгоритмы, так что MySQL может работать даже при малых объемах памяти. Естественно для лучшей производительности нужно больше оперативной памяти.
MySQL
MySQL полезные команды
Журнал общих запросов MySQL general_log_file
Журнал содержит информацию о подключениях клиентов, запросах и другого рода событиях. Это файл очень полезен для отладки,
Percona Toolkit
Компания Percona имеет в своем арсенале кучу утилит для работы с базой под названием percona-toolkit.
Continue Reading
MySQL — ошибка Checking for corrupt, not cleanly closed and upgrade needing tables
Данное сообщение не является ошибкой.
Такой строкой скрипт запуска MySQL рассказывает. что он:
- Проверяет наличие поврежденный таблиц
- Проверяет наличие не закрытых таблиц
- Проверяет наличие не обновленных таблиц, если вы обновили версию MySQL.
- принудительно проверить вcе таблицы для спокойствия
-
mysqlcheck --check-upgrade --all-databases --auto-repair -u root -p mysql_upgrade --force -u root -p
MySQL: “Access denied for user ‘debian-sys-maint’@’localhost'”
For all you Ubuntu/MySQL developers out there, have you ever seen the following?
neo@thematrix:~$ sudo /etc/init.d/mysql restart
* Stopping MySQL database server mysqld <strong>[fail]</strong>
* Starting MySQL database server mysqld [ OK ]
/usr/bin/mysqladmin: connect to server at 'localhost' failed
error: '<strong>Access denied for user 'debian-sys-maint'@'localhost'</strong> (using password: YES)'
So, what is this “debian-sys-maint” user? Well, this MySQL user is created for the Ubuntu to be able to start/stop the database and to carry out other maintenance operations.
Sounds well enough, but then why do I keep running into the “access denied” problem for this user? Well, the issue is that with each update to MySQL, the user’s password in the database is overwritten. Ubuntu seems to go to the file/etc/mysql/debian.cnf
in order to find this user’s password, but obviously the password is out of sync after the update has been applied.
As a result of this behaviour, I’ll run into the “access denied” problem every so often. Thankfully, the solution to this issue is fairly simple.
First, list the contents of the /etc/mysql/debian.cnf
file:
neo@thematrix:~$ sudo cat /etc/mysql/debian.cnf
The contents of the file should look something like the following:
# Automatically generated for Debian scripts. DO NOT TOUCH!
[client]
host = localhost
user = debian-sys-maint
<strong>password = n4aSHUP04s1J32X5</strong>
socket = /var/run/mysqld/mysqld.sock
[mysql_upgrade]
user = debian-sys-maint
<strong>password = n4aSHUP04s1J32X5</strong>
socket = /var/run/mysqld/mysqld.sock
basedir = /usr
See that password? That’s what we’re looking for!
Next, we want to issue a command to MySQL that tells it to grant the debian-sys-maint
user all necessary privileges using the new password.
Login to your mysql server using your root account and the root password you had originally set:
neo@thematrix:~$ mysql -u root -p <password>
Issue the GRANT command now to grant those permissions:
mysql> GRANT ALL PRIVILEGES ON *.* TO 'debian-sys-maint'@'localhost' IDENTIFIED BY 'n4aSHUP04s1J32X5';
Voila! If you restart MySQL, you’ll find that you should no longer be getting the “access denied” error message.
neo@thematrix:~$ sudo /etc/init.d/mysql restart
* Stopping MySQL database server mysqld [ OK ]
* Starting MySQL database server mysqld [ OK ]
* Checking for corrupt, not cleanly closed and upgrade needing tables.
Bear in mind, because we just switched the password, and the change hasn’t been affected yet, you may need to kill the MySQL server processes in order to get MySQL to shut down at all.
Как узнать самые ненужные индексы в MySQL
Наверное, каждая таблица, содержит индексы. Часто, даже количество индексов может превышать количество столбцов в самой таблице.
При составлении индексов, можно создать те, которые будут практически дублировать друг-друга (встречается в составных индексах). А зачем нам тратить лишние ресурсы на обработку данных, которые нам не понадобятся?
Заинтересовал вопрос – а как можно узнать какие индексы незадействованные или мало задействованы в работе.
Выполнив такой запрос, можно узнать про “напрасные” индексы:
SELECT t.TABLE_SCHEMA AS `db`, t.TABLE_NAME AS ` table `, s.INDEX_NAME AS ` index name ` , s.COLUMN_NAME AS `field name `, s.SEQ_IN_INDEX `seq in index `, s2.max_columns AS `# cols` , s.CARDINALITY AS `card`, t.TABLE_ROWS AS `est rows ` , ROUND(((s.CARDINALITY / IFNULL(t.TABLE_ROWS, 0.01)) * 100), 2) AS `sel %` FROM INFORMATION_SCHEMA. STATISTICS s INNER JOIN INFORMATION_SCHEMA.TABLES t ON s.TABLE_SCHEMA = t.TABLE_SCHEMA AND s.TABLE_NAME = t.TABLE_NAME INNER JOIN ( SELECT TABLE_SCHEMA, TABLE_NAME, INDEX_NAME, MAX (SEQ_IN_INDEX) AS max_columns FROM INFORMATION_SCHEMA. STATISTICS WHERE TABLE_SCHEMA != 'mysql' GROUP BY TABLE_SCHEMA, TABLE_NAME, INDEX_NAME ) AS s2 ON s.TABLE_SCHEMA = s2.TABLE_SCHEMA AND s.TABLE_NAME = s2.TABLE_NAME AND s.INDEX_NAME = s2.INDEX_NAME WHERE t.TABLE_SCHEMA != 'mysql' /* Filter out the mysql system DB */ AND t.TABLE_ROWS > 10 /* Only tables with some rows */ AND s.CARDINALITY IS NOT NULL /* Need at least one non- NULL value in the field */ AND (s.CARDINALITY / IFNULL(t.TABLE_ROWS, 0.01)) < 1.00 /* unique indexes are perfect anyway */ ORDER BY `sel %`, s.TABLE_SCHEMA, s.TABLE_NAME /* DESC for best non- unique indexes */ LIMIT 10; |