不需要任何脚本、命令等…

你只需将sqlite数据库导出为.csv文件，然后使用phpmyadmin将其导入Mysql。

我用过，效果非常好……

最近，为了我们团队正在进行的一个项目，我不得不从MySQL迁移到JavaDB。我发现Apache编写的一个名为DdlUtils的Java库非常容易做到这一点。它提供了一个API，让你做以下事情:

发现数据库的模式并将其导出为XML文件。 根据此模式修改DB。 将记录从一个DB导入到另一个DB，假设它们具有相同的模式。

我们最终使用的工具并不是完全自动化的，但它们工作得很好。即使您的应用程序不是用Java编写的，使用一些小工具进行一次性迁移也不会太难。我认为我只用了不到150行代码就完成了迁移。

这个脚本是可以的，除了这种情况，当然，我遇到过:

INSERT INTO "requestcomparison_stopword" VALUES(149,'f');
INSERT INTO "requestcomparison_stopword" VALUES(420,'t');

脚本应该给出这样的输出:

INSERT INTO requestcomparison_stopword VALUES(149,'f');
INSERT INTO requestcomparison_stopword VALUES(420,'t');

而是给出了输出:

INSERT INTO requestcomparison_stopword VALUES(1490;
INSERT INTO requestcomparison_stopword VALUES(4201;

最后0和1周围有一些奇怪的非ascii字符。

当我注释以下代码行(43-46)时，这不再出现，但出现了其他问题:

行= re.sub (r”([^”)“t”(.)”、“this_is_true 1 \ \ 2”、线) Line = Line。替换(' THIS_IS_TRUE ', ' 1 ') 行= re.sub (r”([^])的f '(。)”、“this_is_false 1 \ \ 2”、线) Line = Line。替换(“THIS_IS_FALSE ', ' 0 ')

这只是一个特殊的情况，当我们想要添加一个值是“f”或“t”，但我不太习惯正则表达式，我只是想发现这种情况由某人纠正。

无论如何，非常感谢这个方便的脚本!!

echo ".dump" | sqlite3 /tmp/db.sqlite > db.sql

注意CREATE语句

这个简单的解决方案对我很有效:

<?php
$sq = new SQLite3( 'sqlite3.db' );

$tables = $sq->query( 'SELECT name FROM sqlite_master WHERE type="table"' );

while ( $table = $tables->fetchArray() ) {
    $table = current( $table );
    $result = $sq->query( sprintf( 'SELECT * FROM %s', $table ) );

    if ( strpos( $table, 'sqlite' ) !== false )
        continue;

    printf( "-- %s\n", $table );
    while ( $row = $result->fetchArray( SQLITE3_ASSOC ) ) {
        $values = array_map( function( $value ) {
            return sprintf( "'%s'", mysql_real_escape_string( $value ) );
        }, array_values( $row ) );
        printf( "INSERT INTO `%s` VALUES( %s );\n", $table, implode( ', ', $values ) );
    }
}

最简单的方法可能是使用sqlite .dump命令，在本例中创建示例数据库的转储。

sqlite3 sample.db .dump > dump.sql

然后(理论上)您可以使用root用户将其导入到mysql数据库中，在本例中是数据库服务器127.0.0.1上的测试数据库。

mysql -p -u root -h 127.0.0.1 test < dump.sql

我说在理论上，因为语法之间有一些差异。

在sqlite事务开始

BEGIN TRANSACTION;
...
COMMIT;

MySQL只使用

BEGIN;
...
COMMIT;

还有其他类似的问题(varchars和双引号会回到脑海中)，但没有查找和替换不能解决的问题。

也许你应该问问为什么要迁移，如果性能/数据库大小是问题，也许应该考虑重新规划模式，如果系统正在迁移到更强大的产品，这可能是计划数据未来的理想时机。