StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
17086981
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
0
CommunityOwnedDate
CreationDate
2013-06-13T12:22:26.693
FavoriteCount
0
LastActivityDate
2013-06-13T12:22:26.693
LastEditDate
LastEditorUserId
0
OwnerUserId
417194
ParentId
17086663
PostTypeId
2
Score
0
ViewCount
0
LastEditorDisplayName
text
Body
<blockquote> The second approach is surposed to be faster than the first one,the result is not as what I thought to be though,Could anyone tell me does bindparam() really speed up bulk insertion? </blockquote> It actually is faster. Just not necessarily for trivial queries like the one you posted. This is a bit like benchmarking MySQL vs PostgreSQL. If you run a test with MyISAM tables that does trivial non-concurrent selects, your benchmark might decide that MySQL outperforms Postgres. If, however, you run hundreds of concurrent queries with a half-dozen joins, your benchmark might tell you a very different story. In your case, you're preparing a trivial insert. It's trivial to parse the SQL; determining the optimal query plan is equally trivial. The benefit of preparing the statement is very slim. If, on the other hand, you have a couple of non-trivial triggers that fire on each insert, you'll likely get a very different story. There's also something to be said about true prepares vs emulated prepares. Sometimes, a prepared statement doesn't give you an optimal plan. Consider this query: <pre><code>select * from foo order by bar limit ? </code></pre> If you prepare the above, the planner cannot decide whether to use an index on bar -- if bar is low enough, it'll make sense; if it's enormous, you might as well fetch the entire table and top-n sort it. And so the planner will pick the latter plan. In contrast, if you send the final query directly, the planner will have all the elements it needs to decide whether using that same index makes sense or not for that particular value. In other words, an emulated prepare is occasionally better for queries that are only run a single time, or for trivial queries. Oh, and don't forget to wrap the entire thing into a single transaction. That'll speed things up significantly.
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. PODoes php bindParam() speed up bulk insert?
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. This table or related slice is empty.
UserOwnerUserId
1. USDenis de Bernardy
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. This table or related slice is empty.
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. This table or related slice is empty.
CommentsPostId
1. This table or related slice is empty.

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.