"MySQL is faster than MS SQL Server", Should I believe it?
-
In some cases yes and in some cases no. As an example MySQL supports different table types. Two of those types are ISAM and InnoDB. We moved a database from ISAM to InnoDB to get better performance. Overall InnoDB was faster (it supports row level locking and ISAM does not) but because of the underlying DB structure a simple select count(*) from table was slow on InnoDB whereas it was pretty much instant on ISAM. Todd Smith
-
Or is it "My SQL is faster than yours" time ;P Elaine (fluffy tigress emoticon) Would you like to meet my teddy bear ?
-
Yes, believe it. MySQL (usually) doesn't support transactions, which is why it is so fast. It also doesn't support referential integrity constraints. Their current 4.x development effort is supposed to fix these problems. I can't wait to see how it holds up. :) Jon Sagara Damnit Jim!
-
MySQL does now support transactions. http://www.mysql.com/products/mysql-4.0/index.html[^] Although i've never benchmarked them, i do personally have the touchy-feely feeling that it's quicker. Which kind of doesn't suprise me... mysql's primary goal has always been speed. and, the dev cycle is such that new code gets out to a product release far quicker than MS can. they are driven by commerical process, not technology. mysql still lacks a decent user interface, none of the ones available are anywhere near as useful as query analyser/enterprise manager combo. Signature space for rent. Apply by email to....
Unfortunately, 4.x is still in beta. The version they recommend for production servers doesn't usually support transactions. I know you can enable transactions with 3.23.x, but most web hosts do not. I can't wait for version 4. :) Jon Sagara Damnit Jim!
-
You should qualify that statement to say "MySQL is faster than MS SQL Server when doing SELECT statements." This is true. But, usually only when you load a table into memory. In MySQL you can load a table into the heap and then the engine will run a query against RAM. Faster, yes...but only on SELECT statements against RAM which will be faster than Hard Drive data anyway. Hope that clarified things. :) Your bullshit is so effusive I can smell it across oceans... You impress no-one. You are a world-class sleazeball; an incomparable jerk. No-one is fooled by your idiotic attempts to slant votes. -A. N. Onymous on Bill SerGio
-
You should qualify that statement to say "MySQL is faster than MS SQL Server when doing SELECT statements." This is true. But, usually only when you load a table into memory. In MySQL you can load a table into the heap and then the engine will run a query against RAM. Faster, yes...but only on SELECT statements against RAM which will be faster than Hard Drive data anyway. Hope that clarified things. :) Your bullshit is so effusive I can smell it across oceans... You impress no-one. You are a world-class sleazeball; an incomparable jerk. No-one is fooled by your idiotic attempts to slant votes. -A. N. Onymous on Bill SerGio
But SQLServer caches everything in RAM as well. Take a look at the CodeProject server one day - millions of queries a day and nary a flicker of hard drive activity to be seen. cheers, Chris Maunder
-
But SQLServer caches everything in RAM as well. Take a look at the CodeProject server one day - millions of queries a day and nary a flicker of hard drive activity to be seen. cheers, Chris Maunder
-
So if your server goes down without a UPS backup you're so shafted, so to speak :~ Developing with C++ is like programming by the seat of your pants
Which is why we have a UPS backup :) cheers, Chris Maunder
-
Which is why we have a UPS backup :) cheers, Chris Maunder
-
But SQLServer caches everything in RAM as well. Take a look at the CodeProject server one day - millions of queries a day and nary a flicker of hard drive activity to be seen. cheers, Chris Maunder
Yeah, but what I meant was that in MySQL you can shove stuff into RAM. It's optimized for that. SQLServer has to put the stuff into RAM. And even then, I think that it only puts part of it into ram...:~ Maybe you could ask someone on the SQL Server team about this very issue while you're there Chris...:-D Your bullshit is so effusive I can smell it across oceans... You impress no-one. You are a world-class sleazeball; an incomparable jerk. No-one is fooled by your idiotic attempts to slant votes. -A. N. Onymous on Bill SerGio
-
OK smart ass, which goes sooner your UPS dying or your MS SQL server purging its guts out to disk. ;) Developing with C++ is like programming by the seat of your pants
LOL. cheers, Chris Maunder
-
Yeah, but what I meant was that in MySQL you can shove stuff into RAM. It's optimized for that. SQLServer has to put the stuff into RAM. And even then, I think that it only puts part of it into ram...:~ Maybe you could ask someone on the SQL Server team about this very issue while you're there Chris...:-D Your bullshit is so effusive I can smell it across oceans... You impress no-one. You are a world-class sleazeball; an incomparable jerk. No-one is fooled by your idiotic attempts to slant votes. -A. N. Onymous on Bill SerGio
I don't know what the Codeproject Db looks like (Is there a way to look at it??? ;P) but what you are talking about is a cacheing mechanism found in most RDBMS (Oracle has it, as does DB2. Basically run most any DML and depending on your buffer cache a certain number of blocks/pages are cached to RAM. You can get a really quick query on those till they are flushed/aged out. The buffer cache typically works on a least used, flush queue principle. You can also do what's called pinning/nailing to load tables into memory automatically upon server start... this is great for lookup and small tables with no updating cause they are locked in memory, but try nailing a couple 100 million row table sometime :) KA-BOOM! :omg: Mark
-
I don't know what the Codeproject Db looks like (Is there a way to look at it??? ;P) but what you are talking about is a cacheing mechanism found in most RDBMS (Oracle has it, as does DB2. Basically run most any DML and depending on your buffer cache a certain number of blocks/pages are cached to RAM. You can get a really quick query on those till they are flushed/aged out. The buffer cache typically works on a least used, flush queue principle. You can also do what's called pinning/nailing to load tables into memory automatically upon server start... this is great for lookup and small tables with no updating cause they are locked in memory, but try nailing a couple 100 million row table sometime :) KA-BOOM! :omg: Mark
Oh cool. I had no idea that's how it worked. I knew that you could load MySQL stuff into memory, but I didn't know that SQL Server cached stuff as well. Your bullshit is so effusive I can smell it across oceans... You impress no-one. You are a world-class sleazeball; an incomparable jerk. No-one is fooled by your idiotic attempts to slant votes. -A. N. Onymous on Bill SerGio
-
Oh cool. I had no idea that's how it worked. I knew that you could load MySQL stuff into memory, but I didn't know that SQL Server cached stuff as well. Your bullshit is so effusive I can smell it across oceans... You impress no-one. You are a world-class sleazeball; an incomparable jerk. No-one is fooled by your idiotic attempts to slant votes. -A. N. Onymous on Bill SerGio
I know squat about MySQL but a buffer cache is one of the primary elements in doing server tuning to accomodate load. Otherwise the darn thing goes to disk for evenything so query returns go up an order of magnitude in return time. SQL server I think is a bit weak on how they did this compared to say...Oracle, but it works. The command in SQL Server is to use DBCC PINTABLE. In SQLServer's case it doesn't load the table at server start but at first query. Pages hit by the query are flagged as pinned and then they never age out of the buffer cache and stay there forever. Lots of DBAs cheat and build a job that runs on server start up that does something like a select * or a row count to force all pages into memory. (Can you tell I do this for a living :P) Mark
-
I know squat about MySQL but a buffer cache is one of the primary elements in doing server tuning to accomodate load. Otherwise the darn thing goes to disk for evenything so query returns go up an order of magnitude in return time. SQL server I think is a bit weak on how they did this compared to say...Oracle, but it works. The command in SQL Server is to use DBCC PINTABLE. In SQLServer's case it doesn't load the table at server start but at first query. Pages hit by the query are flagged as pinned and then they never age out of the buffer cache and stay there forever. Lots of DBAs cheat and build a job that runs on server start up that does something like a select * or a row count to force all pages into memory. (Can you tell I do this for a living :P) Mark
Mark Conger wrote: Can you tell I do this for a living :laugh: No. Not at all... ;-) Your bullshit is so effusive I can smell it across oceans... You impress no-one. You are a world-class sleazeball; an incomparable jerk. No-one is fooled by your idiotic attempts to slant votes. -A. N. Onymous on Bill SerGio
-
Mark Conger wrote: Can you tell I do this for a living :laugh: No. Not at all... ;-) Your bullshit is so effusive I can smell it across oceans... You impress no-one. You are a world-class sleazeball; an incomparable jerk. No-one is fooled by your idiotic attempts to slant votes. -A. N. Onymous on Bill SerGio
hehe. Man I need to get a real job :) I've been doing this too long. Mark
-
MySQL does now support transactions. http://www.mysql.com/products/mysql-4.0/index.html[^] Although i've never benchmarked them, i do personally have the touchy-feely feeling that it's quicker. Which kind of doesn't suprise me... mysql's primary goal has always been speed. and, the dev cycle is such that new code gets out to a product release far quicker than MS can. they are driven by commerical process, not technology. mysql still lacks a decent user interface, none of the ones available are anywhere near as useful as query analyser/enterprise manager combo. Signature space for rent. Apply by email to....
Jon Hulatt wrote: MySQL does now support transactions. I checked it some months ago and I didn't read the new release descriptions. I'm sorry for the wrong information I gave. I think that the problem with benchmarks and with database benchmarks in particular is that they are focused on a specific issue and sometime you will find yourself with the DB that is the fastest doing something you don't need :) I think that both oracle and ms have benchmarks showing that their DB is the fastest DB running on a x86 platform and IBM did the same with its DB2... -- Looking for a new screen-saver? Try FOYD: http://digilander.iol.it/FOYD