无效的SQL: SELECT user.,userfield. FROM user LEFT JOIN userfield ON userfield.userid=user.userid WHERE user.userid='1'
mysql数据库错误: Can't open file: 'user.MYD'. (errno: 145)
mysql数据库错误号: 1016
在本机如何解决?如果不是本机能不能解决?如何解决?
---------------------------------------------------------------
如果是本机则
先将计算机重启，再试，
一般能解决大部分的问题，如果还不行，就用MySQL自带的几个修复工具修复吧，
PS：
对于没有什么重要数据的表，你也可以使用 DELETE FROM Table 命令
这个命令会重新建立你的表结构与索引文件，
下面的SQL命令也会有一些作用的
OPTIMIZE TABLE user
CHECK TABLE user
ANALYZE TABLE user
REPAIR TABLE user
mysqlcheck.exe
myisamchk.exe
描述、检查、优化和修复MySQL表的使用程序
myisamchk tbl_name
这能找出所有错误的99.99%。它不能找出的是仅仅涉及数据文件的损坏(这很不常见)。如果你想要检查一张表，你通常应该没有选项地运行myisamchk或用-s或--silent选项的任何一个。
myisamchk -e tbl_name
它做一个完全彻底的数据检查(-e意思是“扩展检查”)。它对每一行做每个键的读检查以证实他们确实指向正确的行。这在一个有很多键的大表上可能花很长时间。myisamchk通常将在它发现第一个错误以后停止。如果你想要获得更多的信息，你能增加--verbose(-v)选项。这使得myisamchk继续一直到最多20个错误。在一般使用中，一个简单的myisamchk（没有除表名以外的参数)就足够了。
myisamchk -e -i tbl_name
象前面的命令一样，但是-i选项告诉myisamchk还显示出一些统计信息。
阶段1：检查你的表
运行myisamchk *.MYI或(myisamchk -e *.MYI，如果你有更多的时间)。使用-s（沉默)选项禁止不必要的信息。
你必须只修复那些myisamchk报告有一个错误的表。对这样的表，继续到阶段2。
如果在检查时，你得到奇怪的错误(例如out of memory错误)，或如果myisamchk崩溃，到阶段3。
舞台 2 ：简单安全的修复
首先，试试myisamchk -r -q tbl_name(-r -q意味着“快速恢复模式”)。这将试图不接触数据文件来修复索引文件。如果数据文件包含它应有的一切和在数据文件指向正确地点的删除连接，这应该管用并且表可被修复。开始修理下一张表。否则，使用下列过程：
在继续前做数据文件的一个备份。
使用myisamchk -r tbl_name(-r意味着“恢复模式”)。这将从数据文件中删除不正确的记录和已被删除的记录并重建索引文件。
如果前面的步骤失败，使用myisamchk --safe-recover tbl_name。安全恢复模式使用一个老的恢复方法，处理常规恢复模式不行的少数情况(但是更慢)。
如果在修复时，你得到奇怪的错误(例如out of memory错误)，或如果myisamchk崩溃，到阶段3。
舞台 3 ：困难的修理
如果在索引文件的第一个16K块被破坏，或包含不正确的信息，或如果索引文件丢失，你只应该到这个阶段 。在这种情况下，创建一个新的索引文件是必要的。按如下这样做：
把数据文件移更安全的地方。
使用表描述文件创建新的(空)数据和索引文件：
shell> mysql db_name
mysql> DELETE FROM tbl_name;
mysql> quit
将老的数据文件拷贝到新创建的数据文件之中。（不要只是将老文件移回新文件之中；你要保留一个副本以防某些东西出错。）
回到阶段2。现在myisamchk -r -q应该工作了。（这不应该是一个无限循环)。
阶段4：非常困难的修复
只有描述文件也破坏了，你才应该到达这个阶段。这应该从未发生过，因为在表被创建以后，描述文件就不再改变了。
从一个备份恢复描述文件并且回到阶段3。你也可以恢复索引文件并且回到阶段2。对后者，你应该用myisamchk -r启动。
如果你没有一个备份但是确切地知道表是怎样被创建的，在另一个数据库中创建表的一个拷贝。删除新的数据文件，然后从其他数据库将描述和索引文件移到破坏的数据库中。这给了你新的描述和索引文件，但是让数据文件独自留下来了。回到阶段2并且尝试重建索引文件。