5 ms·

That's why prepared statements are preferable because those two statements have to be parsed as unique queries. They are actually the same query with different

• nikita 14y ago
  Not every parsing is equal. MySQL and other databases produce a tree as they parse a query. If you just want to match parameters you can avoid memory allocations and just replace parameters with ^ or @ signed in place in the query string. http://developers.memsql.com/docs/1b/faq.html http://developers.memsql.com/docs/1b/faq.html gives some more details.
• dhruvbird 14y ago
  @nikita I see: http://developers.memsql.com/docs/1b/faq.html#does-this-mean-that-if-i-change-a-constant-in-a-query-memsql-will-compile-a-new-plan http://developers.memsql.com/docs/1b/faq.html#does-this-mean... Do you mean you determine placeholders without actually parsing the SQL? @jakejake The docs. seem to suggest that the benefits of prepared statements are won without using prepared statements in MemSQL.
• bazzargh 14y ago
  At least some databases I've used have parsed out constants in the client library code and submitted prepared statements to the server, passing those constants in. That meant that the server got better use out of its query cache; on the server side, those are the same query. Not sure which ones if any do this today, the optimisation might no longer be relevant - I spotted DBs doing this 10 years ago when CGIs that didn't bother with prepared statements were rife.