插入与插入

They both do the same thing. INTO is optional (in SQL Server's T-SQL) but aids readability.

INSERT INTO is the standard. Even though INTO is optional in most implementations, it's required in a few, so it's a good idea to include it to ensure that your code is portable.

You can find links to several versions of the SQL standard here. I found an HTML version of an older standard here.

It may be optional in mySQL, but it is mandatory in some other DBMSs, for example Oracle. So SQL will be more potentially portable with the INTO keyword, for what it's worth.

They are the same thing, INTO is completely optional in T-SQL (other SQL dialects may differ).

Contrary to the other answers, I think it impairs readability to use INTO.

I think it is a conceptional thing: In my perception, I am not inserting a row into a table named "Customer", but I am inserting a Customer. (This is connected to the fact that I use to name my tables in singular, not plural).

If you follow the first concept, INSERT INTO Customer would most likely "feel right" for you.

If you follow the second concept, it would most likely be INSERT Customer for you.

I prefer using it. It maintains the same syntax delineation feel and readability as other parts of the SQL language, like group BY, order BY.

One lesson I leaned about this issue is that you should always keep it consistent! If you use INSERT INTO, don't use INSERT as well. If you don't do it, some programmers may ask the same question again.

Here is my another related example case: I had a chance to update a very very long stored procedure in MS SQL 2005. The problem is that too many data were inserted to a result table. I had to find out where the data came from. I tried to find out where new records were added. At the beginning section of SP, I saw several INSERT INTOs. Then I tried to find "INSERT INTO" and updated them, but I missed one place where only "INSERT" was used. That one actually inserted 4k+ rows of empty data in some columns! Of course, I should just search for INSERT. However, that happened to me. I blame the previous programmer IDIOT:):)

If available use the standard function. Not that you ever need portability for your particular database, but chances are you need portability for your SQL knowledge. A particular nasty T-SQL example is the use of isnull, use coalesce!

In SQL Server 2005, you could have something in between INSERT and INTO like this:

INSERT top(5) INTO tTable1 SELECT * FROM tTable2;

Though it works without the INTO, I prefer using INTO for readability.

I started wtiting SQL on ORACLE, so when I see code without INTO it just looks 'broken' and confusing.

Yes, it is just my opinion, and I'm not saying you should always use INTO. But it you don't you should be aware that many other people will probably think the same thing, especially if they haven't started scripting with newer implementations.

With SQL I think it's also very important to realise that you ARE adding a ROW to a TABLE, and not working with objects. I think it would be unhelpful to a new developer to think of SQL table rows/entries as objects. Again, just me opinion.

INSERT INTO is SQL standard while INSERT without INTO is not SQL standard.

I experimented them on SQL Server, MySQL, PostgreSQL and SQLite as shown below.

In addition, I also experimented DELETE FROM and DELETE without FROM on SQL Server, MySQL, PostgreSQL and SQLite as shown below: