关于MySQL在运行XAMPP时无法启动，有几个问题，但不幸的是我无法找到解决方案。
这是我的情况： 我为Linux 5.6.14-3安装了XAMPP，当我昨天运行它时一切正常。 今天，我再次运行XAMPP：
/opt/lampp$ sudo ./xampp start
Starting XAMPP for Linux 5.6.14-3...
XAMPP: Starting Apache...ok.
XAMPP: Starting MySQL...ok.
XAMPP: Starting ProFTPD...ok.
然后我在浏览器中打开localhost，将我带到xampp仪表板。在那里我点击了phpMyAdmin菜单条目，它给了我：
Error
MySQL said:
Cannot connect: invalid settings.
Connection for controluser as defined in your configuration failed.
phpMyAdmin tried to connect to the MySQL server,
and the server rejected the connection.
You should check the host, username and password
in your configuration and make sure that they
correspond to the information given by the
administrator of the MySQL server.
我认为我确保控制用户有正确的传球。
问题似乎是MySQL并没有真正启动，尽管它说'ok'（见上文）。因为，当我停止XAMPP时，我得到：
/opt/lampp$ sudo ./xampp stop
Stopping XAMPP for Linux 5.6.14-3...
XAMPP: Stopping Apache...ok.
XAMPP: Stopping MySQL...not running.
XAMPP: Stopping ProFTPD...ok.
查看xampp的error_log，有一个条目，看起来很可疑（虽然我真的不明白），说：
[Sun Nov 15 11:38:59.737875 2015] [mpm_prefork:notice] [pid 6217] AH00169: caught SIGTERM, shutting down
所以，如果有人能够找到问题或给我一些解决方案的提示，我真的会感到沮丧。谢谢！
这是MySQL错误日志（位于/opt/lampp/var/mysql/[computername].err）：
2015-11-15 15:52:44 10864 mysqld_safe Starting mysqld daemon with databases from /opt/lampp/var/
2015-11-15 15:52:44 140410457307008 [Note] Using unique option prefix 'key_buffer' is error-prone and can break in the future. Please use the full name 'key_buffer_size' instead.
2015-11-15 15:52:44 140410457307008 [Note] /opt/lampp/sbin/mysqld (mysqld 10.1.8-MariaDB) starting as process 11011 ...
2015-11-15 15:52:44 140410457307008 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2015-11-15 15:52:44 140410457307008 [Note] InnoDB: The InnoDB memory heap is disabled
2015-11-15 15:52:44 140410457307008 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2015-11-15 15:52:44 140410457307008 [Note] InnoDB: Memory barrier is not used
2015-11-15 15:52:44 140410457307008 [Note] InnoDB: Compressed tables use zlib 1.2.8
2015-11-15 15:52:44 140410457307008 [Note] InnoDB: Using CPU crc32 instructions
2015-11-15 15:52:44 140410457307008 [Note] InnoDB: Initializing buffer pool, size = 16.0M
2015-11-15 15:52:44 140410457307008 [Note] InnoDB: Completed initialization of buffer pool
2015-11-15 15:52:44 140410457307008 [Note] InnoDB: Highest supported file format is Barracuda.
2015-11-15 15:52:44 140410457307008 [Note] InnoDB: The log sequence numbers 3813213 and 3813213 in ibdata files do not match the log sequence number 9929741 in the ib_logfiles!
2015-11-15 15:52:44 140410457307008 [Note] InnoDB: Database was not shutdown normally!
2015-11-15 15:52:44 140410457307008 [Note] InnoDB: Starting crash recovery.
2015-11-15 15:52:44 140410457307008 [Note] InnoDB: Reading tablespace information from the .ibd files...
2015-11-15 15:52:44 140410457307008 [ERROR] InnoDB: Attempted to open a previously opened tablespace. Previous tablespace bitnami_joomla/jos_content_frontpage uses space ID: 14 at filepath: ./bitnami_joomla/jos_content_frontpage.ibd. Cannot open tablespace phpmyadmin/pma__bookmark which uses space ID: 14 at filepath: ./phpmyadmin/pma__bookmark.ibd
2015-11-15 15:52:44 7fb3db6e3780 InnoDB: Operating system error number 2 in a file operation.
InnoDB: The error means the system cannot find the path specified.
InnoDB: If you are installing InnoDB, remember that you must create
InnoDB: directories yourself, InnoDB does not create them.
InnoDB: Error: could not open single-table tablespace file ./phpmyadmin/pma__bookmark.ibd
InnoDB: We do not continue the crash recovery, because the table may become
InnoDB: corrupt if we cannot apply the log records in the InnoDB log to it.
InnoDB: To fix the problem and start mysqld:
InnoDB: 1) If there is a permission problem in the file and mysqld cannot
InnoDB: open the file, you should modify the permissions.
InnoDB: 2) If the table is not needed, or you can restore it from a backup,
InnoDB: then you can remove the .ibd file, and InnoDB will do a normal
InnoDB: crash recovery and ignore that table.
InnoDB: 3) If the file system or the disk is broken, and you cannot remove
InnoDB: the .ibd file, you can set innodb_force_recovery > 0 in my.cnf
InnoDB: and force InnoDB to continue crash recovery here.
2015-11-15 15:52:44 10864 mysqld_safe mysqld from pid file /opt/lampp/var/mysql/[computername].pid ended
首先尝试：我备份了目录/ opt / lampp / var / mysql / phpmyadmin /并添加了
innodb_force_recovery = 1
接下来尝试从目录中删除文件pma__bookmarks.idb，这会导致错误现在抱怨pma__favorites。
最后，我删除了所有pma __ * .idb文件，瞧！ MySQL正在运行，我可以访问phpMyAdmin页面。
对我有用，虽然我不知道删除pma数据库会丢失什么？ （他们似乎没有以任何方式恢复，因为它似乎......）
当我的计算机出现故障时，数据库文件可能已损坏，并且它们仍在运行！？
答案 0 :(得分：1)
您必须检查top中是否存在mysqld进程，然后尝试连接mysql命令行客户端或查看MySQL错误日志。有时xampp可能会被MySQL服务器混淆，例如预安装了操作系统。