InstantForum.NET v2.9.0SQLServerCentralhttp://www.sqlservercentral.com/Forums/notifications@sqlservercentral.comWed, 19 Jun 2013 01:04:50 GMT20http://www.sqlservercentral.com/Forums/Topic548847-1149-1.aspxOne of the MYD files is 100 gb and another is 40 gb. For both these tables, the indexes were defined before any data was put in. The tables were then populated using load data infile and a trigger to create the geometry object. As such, I can't really tell how long the index creation took, as it was all part of the overall load process, which did take 3 days on one of the tables. It is likely that the index creation would have taken a very long time, had I done it after data load, as MyISAM tables are completely rewritten in the process.Now that these tables and indexes are set up, I can do several thousand inserts a second, of fairly complex polygonal data, which I consider acceptable. My config file for sort buffer size, etc, is more or less the same as the sample huge.ini that comes with MySQL, as the box in question, is as 64-bit beast that only runs MySQL.Tue, 22 Sep 2009 04:30:29 GMTjohn.powell-698372http://www.sqlservercentral.com/Forums/Topic548847-1149-1.aspxI've seen issues building indexes on large tables taking excessive amounts of time on anything over 50 GB keys. As I understand it this is do to the sorting process. In fact I've actually asked mysql at performance class on this issue and the answer is to build the keys and tables offline then replace the underlying files. I'd be curious how large your indexes are, and what your mem config is.Mon, 21 Sep 2009 12:06:07 GMTkenk-601293http://www.sqlservercentral.com/Forums/Topic548847-1149-1.aspxI'm interested to know what you mean by large datasets and in what contexts. I have run some moderately large spatial tables in MySQL -- the biggest being several billion rows and around 450 GB of disk space -- and not really had any issues, either on Windows or linux boxes. However, these are MyISAM tables and are largely read only, other than some large updates every few weeks, which I do on a second instance.Mon, 21 Sep 2009 11:11:58 GMTjohn.powell-698372http://www.sqlservercentral.com/Forums/Topic548847-1149-1.aspxMysql does get into trouble with larger datasets, and there is a lot of hacking you need to do. If your talking about single instances of Mysql in a corp env then sql server is most likely a better bet. However if your talking about a cloud env of 10 or more DB servers being accessed by over the internet the per proc license for SQL Server will usually be more expensive then any Dev time required to get mysql to work.Mon, 21 Sep 2009 10:25:42 GMTkenk-601293http://www.sqlservercentral.com/Forums/Topic548847-1149-1.aspxI have MySQL running on a 4X (dual core) 16 GB machine. I was using INNODB, but it kept running into locking errors. I had increased the innodb_buffer_pool_size, and that made some difference, but it was still taking forever. I was inserting millions of records into the database from a different database on the same server. So I moved back to MyISAM and removed all my INNODB changes from my.cnf. This however did not solve the problem either. For some reason I had to put the changes back to the innodb_buffer_pool_size even though I was using MyISAM. I don't understand this but it did make a difference. Even still it is still a very slow import process. We finally changed the architecture, so we import to a staging SQL Server, then use SSIS to make the needed modifications/merges and then write to MySQL. I would have to say its not been even close to a cost savings when we factor in troubleshooting time and no ETL tool (so we still have to use SSIS).Mon, 21 Sep 2009 07:56:21 GMTbnordberghttp://www.sqlservercentral.com/Forums/Topic548847-1149-1.aspxWe've used MySQL for some intense projects in the past. The problems that we encountered tended not to be with MySQL itself. I had queries that choked in the application but would run fine in SQLyog. It was the .NET connectors. I one failed project (yes, I've had them too) while the database performance was an issue it was not the killer.I also have been fearful of the takeover. At first I thought about the the "buy it to kill it" thing. More likely it will be the "let's merge all the teams so that we can look like we are saving money" thing. It's a slow poison. All the stuff that people hate about A (and the reason they didn't but it) will bleed into B. When B dies a slow death then the hymn sung over the grave would sound like "We were right with the first product all along." We have all seen this before.No as to one entity owning two some what competing products. I don't see that much of an issue. Case in point is Microsoft owning Apple. In the car wars Buick competed with Oldsmobile. Mercury competes with Ford.Mon, 21 Sep 2009 07:11:35 GMTCharles Kincaidhttp://www.sqlservercentral.com/Forums/Topic548847-1149-1.aspxThere's just that one little new piece to add to the puzzle - Oracle taking over MySQL. That changes everything. In a bad way. The thing most MSSQL database people will notice when they first get into MySQL is how similar the two products are in terms of their functions, data types, etc. Even in .NET, you can take many database object instances, like SqlDataAdapter for example, and just make it MySqlDataAdapter, and it works. I think that is going to change, and we will see much more PL/SQL-like syntax. THAT is the worst part. Personally, I manage DB2, MySQL, and MSSQL, and there is no doubt in my mind that MS has the best product of the three.Sat, 19 Sep 2009 05:48:37 GMTSQL-DBAhttp://www.sqlservercentral.com/Forums/Topic548847-1149-1.aspxThe thing that impresses me most about MySQL are the MySQL tech staff. These are a bunch of guys I consider myself privileged to have worked with.The trainers were also pretty hot. Neither group gives any sales BS. They are totally upfront and honest about what their product will and won't do. That means they inspire confidence.Being upfront about the limitations means that we design a solution accordingly.We looked at the various engines when we evaluated MySQL.Memory engine is fast but writes cause table locks. Also all strings become fixed length. VARCHAR(255) becomes CHAR(255). As a non-expiring cache it is unsurpassed.Blackhole engine will run any SQL statement it just doesn't store data. It is useful as a relay station for replication. Replication is Master to Slave and the MySQL guys recommend that the maximum number of slaves is 8. Go beyond this and you replicate to 8 black holes, each of which have 8 slaves.Archive engine is really a compressed MyISAM.One of the MySQL guys told me that the origins of the pluggable engine architecture came about because the developers didn't like having to wait to recompile MySQL so they split the storage and query engines to shorten recompile times. Serrendipity!As for size, it depends on what you are doing. For a read-only store you can get really big databases. One of ours in near 1TB and gives acceptable performance.MySQL also works well if you want massive write capability such as a logging application. Where it all gets a bit hectic is if you want massive reads AND writes.Backups are a pain. We really need a Litespeed equivalent for compressed backups.Although I have seen religious flame posts on DB engines there seems to be less of it than with, say, OS flame wars. I'm probably wrong but I feel that DBAs are interested in databases and database technology per se rather than any particular heresy.Sat, 19 Sep 2009 05:14:49 GMTDavid.Poolehttp://www.sqlservercentral.com/Forums/Topic548847-1149-1.aspxHi David.I never really had any problem with the MySQL engines themselves. If I stuck with myISAM I got single table backups and single table restores out of the box. Too cool for school, that.My performance problems were all in the connector. Queries that ran, or crawled rather, in the application came back instantly when pasted into SQLYog. It's was a hot server on a clean network and all inside the four walls. The latest and greatest of all components too. I wish that I [b][i][u]could[/u][/i][/b] share real world statistics with you but that is all tucked away in the project folders under the confidentiality blanket.Then is have to look at what, IMHO, is the crippled way they implemented triggers, functions, and stored procedures. I can't wait for MySQL to "grow up" in this area. You can read that both ways. One, I'm hoping they do and anticipating the need for another look, and Two, I'm not waiting but moving forward without them. Sad really.It turned out, for us, that the low cost of acquisition was not enough to overcome the issues.MySQL is a great thing and will work well for many people. It has feature sets and attributes that can make it "killer" in lots of places.Thu, 02 Jul 2009 10:09:17 GMTCharles Kincaidhttp://www.sqlservercentral.com/Forums/Topic548847-1149-1.aspxWe've been evaluating MySQL Vs SQL2008. So far the cheapness of MySQL means that a scaleout architecture is a practical proposition. Performance wise scale-up is not so hot. Go beyond 4CPU and see what happens.NDB is brilliant for ultra-high concurrency reads. Sun don't recommend going beyond 8 data nodes though in theory you can go up to 48. Bear in mind you lose the performance if you start doing joins between tables so you have to be careful about what you want to do.With the religious flame wars you get emotive statements rather than scientific facts so you get statements such as MySQL InnoDB out-performs SQL Server or vice verse.Great, which version of each engine, what hardware spec, doing what?Thu, 02 Jul 2009 08:11:29 GMTDavid.Poolehttp://www.sqlservercentral.com/Forums/Topic548847-1149-1.aspxJust in case someone's looking to install.. The best bet is to use the appropriate package manage rather than the manual install described a few posts earlier. For Debian based systems, that would be apt-get as described (this includes Ubuntu). For rpm based systems such as RedHat or Suse, use the appropriate package manager. It will make the install even easier than a Windows install.Mon, 11 Aug 2008 06:41:19 GMTSamuel Cloughhttp://www.sqlservercentral.com/Forums/Topic548847-1149-1.aspxApologies: the Debain linux install command should be sudo apt-get install mysql-server not sudo apt-cache as I wrote above.Mon, 11 Aug 2008 01:39:10 GMTjohn-839610http://www.sqlservercentral.com/Forums/Topic548847-1149-1.aspxIf you are using Debian linux, you can install MySQL with a simple: sudo apt-cache install mysql-server. This will take care of all the group and user creations, the mysql_install_db script, etc. It will also all a script to init.d which will start the server automatically when the machine restarts, something that was missed out of the instructions above.The windows installer is almost as easy. Download the installer and run and all you need to do is answer basic questions about the installation.To fine tune MySQL you need to play with a file called my.cnf which under linux lives in /etc/my.cnf and using the windows installer end up in the MySQL Server [version] directory.my.cnf allows you to set parameters concerning how much memory is allocated for the query cache, for joins, which port to accept connections on (default is 3306), where the data lives, how many letters to include in a full-text index, etc, etc. You can even use two versions of my.cnf to run two instances of MySQL on the same box using different ports and set the path to my.cnf when you install the db, ie, when you run mysql_install_db.The MySQL manual is an excellent source of information for all of this http://dev.mysql.com/doc/ as it includes the official documentation from the MySQL developers and also lots of helpful comments from users to avoid gotchas.Mon, 11 Aug 2008 01:37:48 GMTjohn-839610http://www.sqlservercentral.com/Forums/Topic548847-1149-1.aspxNice article... Atif SheikhSat, 09 Aug 2008 01:48:25 GMTAtif-ullah Sheikhhttp://www.sqlservercentral.com/Forums/Topic548847-1149-1.aspxGreat Article....:)Sat, 09 Aug 2008 01:39:25 GMTAnipaulhttp://www.sqlservercentral.com/Forums/Topic548847-1149-1.aspxI’m not sure if Steve wants to turn this into a mysql tutorial site. If you’re coming from a windows background the install can be more difficult then working with the database. I’ll post something on my blog and give the url once complete. Until then here’s a quick step through list provided by mysql: shell> groupadd mysqlshell> useradd -g mysql mysqlshell> cd /usr/localshell> gunzip < /path/to/mysql-VERSION-OS.tar.gz | tar xvf -shell> ln -s full-path-to-mysql-VERSION-OS mysqlshell> cd mysqlshell> chown -R mysql .shell> chgrp -R mysql .shell> scripts/mysql_install_db --user=mysqlshell> chown -R root .shell> chown -R mysql datashell> bin/mysqld_safe --user=mysql &Fri, 08 Aug 2008 17:51:54 GMTSQLKenhttp://www.sqlservercentral.com/Forums/Topic548847-1149-1.aspxThanks for the article, Ken, very informative. It wasn't what I was expecting, I was expecting more of a command-level or operational level rather than storage engine level. Still, good information. I've always wondered what difference the storage engine made, and now I know.I've tried to get MySQL working on my various platforms but always had problems, it was a couple of generations ago and hopefully they've made substantial improvements to their installers. In the books that I've read I was impressed by how close their syntax is to T-SQL and ANSI, it made me feel that the learning curve from a syntactic standpoint wouldn't be too great. One thing that I thought was really cool was the backup scripting out the table structure in addition to making the data a series of insert statements.Currently I have it pre-installed on my web sites (on RHE) as a standard package supporting and supported by Fantastico, running a few Small Machines Forum message boards, a chat engine, and now my Wordpress blog. I quite like the power and stability, and the PHP admin interface works well, though it takes a little getting used to.To add my $0.002 worth to suggestions for future articles, how about an installation walk-through? I know I could find plenty online, but it would be nice to see one from someone that we know, so to speak. I'd also like to see an article illustrating how to do stored procedures in MySQL.Not that there's any pressure for you to write more articles for us here.... :hehe:Fri, 08 Aug 2008 14:13:17 GMTWayne Westhttp://www.sqlservercentral.com/Forums/Topic548847-1149-1.aspx[quote][b]Samuel Clough (8/8/2008)[/b][hr]I'm sorta amazed that this thread hasn't become a religious war...[/quote]We're a pretty laid back group here, I think it's the patchouli that Steve pipes through our connections.:DFri, 08 Aug 2008 14:05:04 GMTWayne Westhttp://www.sqlservercentral.com/Forums/Topic548847-1149-1.aspxWe haven't used any SAN's we've stayed to single box solutions (HP 165/185/385/585). On the PK I referenced earlier we needed to query individual records on a dataset of 600 million rows in under 20 ms. Due to the particulars of the query it had to come off a b-tree in memory. We tried innodb, but the load times took to long. The index itself was 14 bytes, so we didn’t want to use ndb as we were getting close to our memory limitations on the box. So we created the b-tree on a myisam structure and pinned it using the query cache. In retrospect the memory engine would most likely have been a better choice.Fri, 08 Aug 2008 13:36:24 GMTSQLKenhttp://www.sqlservercentral.com/Forums/Topic548847-1149-1.aspxAll our installs have been all 64 bit mostly using 16 GB of memory, with some using 8. The ease and sturdiness of replication has been a significant benefit for redundancy as well as splitting applications up between read and write. I hear in 6.0 they'll be leveraging replication to provide a synchronous mirror type env. One of the nice features of SQL Servers replication model is the fact that the transactions are stored in the distribution database, and I've been looking at a way to leverage the MSrepl_commands table so that we can replicate out to mysql.it should work fine then. Are you using a SAN?Have you tried switching few tables to innoDB and run some query tests?I think one important missing feature in MySQL is a Query is not able to use multiple indexes for 1 table. Always uses 1 index per query per table.And the explain command is limited. MS SQL Query plan and Statistic io is a really good way to improve perf.Fri, 08 Aug 2008 13:33:25 GMTfranck.leveneurhttp://www.sqlservercentral.com/Forums/Topic548847-1149-1.aspxAll our installs have been all 64 bit mostly using 16 GB of memory, with some using 8. The ease and sturdiness of replication has been a significant benefit for redundancy as well as splitting applications up between read and write. I hear in 6.0 they'll be leveraging replication to provide a synchronous mirror type env. One of the nice features of SQL Servers replication model is the fact that the transactions are stored in the distribution database, and I've been looking at a way to leverage the MSrepl_commands table so that we can replicate out to mysql.Fri, 08 Aug 2008 13:25:55 GMTSQLKenhttp://www.sqlservercentral.com/Forums/Topic548847-1149-1.aspx[quote][b]bnordberg (8/8/2008)[/b][hr]Is anyone else having issues with MySQL's documentation and addition/removal of features? Things like database renaming (added then removed), local file imports having to use the option -L (was optional, now required) ... It seems like each release, no matter how minor, means I have to re-learn everything. Scripts I save in 1 version fail when run against the next minor release. I realize things like the database renaming were better off removed as they did not work at all. But how about fixing instead of just removing!Also I would have to agree with performance issues, I have tables with 144 million rows, in MyISAM and the performance is worse than that of an MS Access DB!Overall MySQL is not my DB of choice - SQL Server, Oracle and Sybase are better in every aspect. But MySQL is free, so I guess its worth all my time re-writing scripts!?[/quote]Are you using a SAN?How about indexes?MyIsam is not best for PK lookup.Fri, 08 Aug 2008 12:59:22 GMTfranck.leveneurhttp://www.sqlservercentral.com/Forums/Topic548847-1149-1.aspxThanks for the interesting article. [u]NDB[/u]"This is a true cluster". Yes you're right. And I think the cluster probably starts scaling even more when you have 4, 6, 8 , or 16 nodes. Something you can't do on MS SQL.SQL Server Cluster is just a fail over solution, (or hot stand by), where SQL resources are switched to another physical box. But SQL resources are not shared among the 2 physical boxes.Mysql also offers a fail over solution (DRDB i think). We're using Veritas cluster on Unix.We also have a 64 bit, 16 CPU, 32 GB RAM and a SAN. CPU is sleeping all day long, yawning.[u]MyISAM[/u].Yes, it's fast, for FullText search. Not meant for PK look up. (innoDB is faster for this).[u]Replication[/u]I would also have written something about replication.MS SQL replication is just pure pain. Mysql is so easier to set up and offer lots of features like 1 master, 1,2, 10 slaves, 1 master 1 slave which replicates to other slaves. Another nice things is you can have innoDB on master (for the writes) then MyIsam on the slave (for the reads).The Web is 80-90% read in general. We're also converting our TextML server to myIsam until we find better solution on Unix.I would have loved to see your hardware configuration. Did you use any 64 bit?Anyway, great article. I think Mysql is really getting some traction in big corpo. Franck L.Sr SQL DB (10+ years) and MySQL DBA (3 years)Fri, 08 Aug 2008 12:56:13 GMTfranck.leveneurhttp://www.sqlservercentral.com/Forums/Topic548847-1149-1.aspxThe long running query log falls a bit short in an oltp environment, because it can only be set at the second level. For example if you want to track queries running over 100 ms, you can't use this feature out of the box. I say out of the box, because I know there is a tweak to the source code you can compile that does provide this functionality. Fri, 08 Aug 2008 11:37:58 GMTSQLKenhttp://www.sqlservercentral.com/Forums/Topic548847-1149-1.aspxI'm sorta amazed that this thread hasn't become a religious war...You can use both innodb and MyIsam for very large datasets. In fact, a lot of the most popular web sites use MySQL. The best thing is to contact MySQL and talk with someone very familiar with what you are trying to do and then see how it compares.There are third party backup solutions for MySQL. There's also mysqldump which is nice to dump a small database (schema and data). Sorta like Oracle's datapump but text based.I'm sure MySQL could point you in the right directory for query tuning, but one nice feature was the slow running query log. You could activate it and MySQL would write any query that ran long to a text log file. You could then begin optimizing with the queries causing the most trouble. Quite helpful if you ask me.Others have mentioned PostgreSQL. Postgres is another nice database. To me, Postgres tends to track Oracle and MySQL is more like a MSSQL (yes I know there are missing features), but it's always dangerous to make those comparisons :^).Fri, 08 Aug 2008 11:12:32 GMTSamuel Cloughhttp://www.sqlservercentral.com/Forums/Topic548847-1149-1.aspxAs a reply to the large datasets, myisam grew out the data warehouse world and understand it can handle large datasets. However the comment is based on the experience of building a 12 GB primary key on a 20 GB dataset. The process took over 36 hours to complete on a HP 585 with 16 GB of memory.Fri, 08 Aug 2008 10:26:30 GMTkenk-601293http://www.sqlservercentral.com/Forums/Topic548847-1149-1.aspxNice intro. My company is evaluating MySQL with a variety of expectations depending on with whom you speak. We are primarly MS SQL and Oracle off-host ( non-DB2 ). The core DB group has little experience in the Open Source arena but are looking to remedy that shortly. While I agree MySQL definitely has a place (cost, especially when looking at Oracle...yeeesh) and fits in, I'm a stodgy "old-timer" trying to redeem myself from my propreitary db ways. My initial research raises concerns, particularly the supportability of MySQL in large enterprise environments regarding:- Environments with high concurrency demands, not just reads but high transactional volume. I'm under the impression this could be ugly.- Lack of good backup technology. Having to lock all my tables to get a file level backup reduces availability somewhat unless you get fancy with your volume managers.- Enterprise level security. Sometimes regulatory requirements impose requirements in this regard. For example, audit capabilities (DCL, DML, DDL, Logins etc ), account configuration ( password complexity, ability to lock accounts after x bad logins or at all! etc ). These features seem lacking in MySQL that were at least somewhat addressed in MS SQL 2005.- Operational support/performance tuning aids. Oracle has the wait interface, tracing, ASH etc. MS SQL has profile among other features. What does MYSQL have....crickets. If I have a poor performing process what would I use? Instance wide stats are not going to cut it at that level. However, perhaps I've not gotten to that level in my researching yet....- Vendor support...okay, this is the bigot in me. I know this can be purchased from Novell, Sun...etc. It would be interesting to know how this check box has been addressed by others. When a system is down...its nice to call somebody and get a quick answer rather than some forum with sometime dubious answers.I agree I'd love to hear more about your experiences with these topics. Explaining additional comments like Innodb being a scaled down version of MySQL. Do you mean performance or in terms of robustness of functionality? etc.ThanksFri, 08 Aug 2008 10:02:19 GMTWhoMovedMyCheesehttp://www.sqlservercentral.com/Forums/Topic548847-1149-1.aspxJust to pile on, I agree it was an interesting article and cleared some things up for me. It has been a few years since I have looked a MySQL mainly because I have worked in MS shops and I am more concerned with being a credible expert in MSSQL than learning open source. My only comment is that from a tools perspective, MSSQL beats out MySQL or at least did when I last looked at it.Fri, 08 Aug 2008 08:51:03 GMT Jack Corbetthttp://www.sqlservercentral.com/Forums/Topic548847-1149-1.aspxThis was a very informative article. I would join the call to expand it into a series going into more detail on the differences and when it is appropriate to use MySQL along side MsSQL.Fri, 08 Aug 2008 08:43:30 GMTtimothyawisemanhttp://www.sqlservercentral.com/Forums/Topic548847-1149-1.aspxI would really love to see this same type of article written for PostgreSQL vs. MSSQL.Fri, 08 Aug 2008 08:33:41 GMTSQL-DBAhttp://www.sqlservercentral.com/Forums/Topic548847-1149-1.aspxbnordberg I think you must have some serious config issues if you are finding a myisam table's performance to be worse than access.Some of these posts really get to the crux of the issue in any MSSQL vs MYSQL debate. With SQL server pretty much what you see is what you get. MySQL is infinitely configurable, which can be difficult at first, but is incredibly rewarding once you get past the first few gotchas. Hell, you can even add your own functions and recompile if you so wish. In fact, MySQL is the first thing I ever built from source, a painful experience to begin with. Now, I am an ecstatic linux hacker and would never go back to black boxes and closed source. It all comes down to budget levels, comfort zones and what you need it for. As I said above, I used MySQL initially as it had a feature that SQL server didnt' have until 2008, namely spatial extensions and R-tree indexes.Fri, 08 Aug 2008 08:03:24 GMTjohn-839610http://www.sqlservercentral.com/Forums/Topic548847-1149-1.aspxIn present times when companies are looking to add projects and cut costs open source is a very viable option. In my experience more than 75% of the SQL Server projects would work well on MySQL. At an internet company I worked at we used MySQL for over 300GB of data. There are great analysis tools for it and lots of community driven support.Where I do see a vacuum in the open source world as it relates to databases is ETL & multidimensional databases. There are some recent projects in this area of BI, but they are not close to as mature as the commercial offerings from companies like Business Objects or Oracle.I would also recommend sticking with InnoDB for enterprise projects because of transactional support, performance and supportability of large databases.Fri, 08 Aug 2008 07:44:18 GMTscott.w.whitehttp://www.sqlservercentral.com/Forums/Topic548847-1149-1.aspxIf you haven't yet, bnordberg, you may want to take a look at PostgreSQL; it's also free and I would expect the learning curve to be a bit more reasonable for someone with a MS SQL Server/Oracle/Sybase background.Cheers.Fri, 08 Aug 2008 07:38:22 GMTcadaverous.scribehttp://www.sqlservercentral.com/Forums/Topic548847-1149-1.aspxGreat article. I'm almost surprised that this has not drawn more fire ... er ... posts. It's early in the US though.The cost of MySQL is great. The open source thing is a bit to get over at first. I can download it and use it myself. My customer can download it and use it. I can't download it and install it for them. We give the customer a sheet of instructions and set with them while they download it and install it. Once done the sheet says, "Now your consultant can be engaged to reconfigure and tune the installation." :cool:The other thing about MyIsam is the way you can do backups. Stop the service, copy the files, start the service. Restore is the same way. To reinstall run your create table scripts and do the restore. This won't work with the other engines.The GUI admin was not built into version 4. SqlYog to the rescue. Version 5 has a lot of new cool stuff in it. Since we have become MS partners we do a lot less with MySQL. We have to support the stuff in the field still. The stuff runs every day.Fri, 08 Aug 2008 07:29:31 GMTCharles Kincaidhttp://www.sqlservercentral.com/Forums/Topic548847-1149-1.aspxGreat intro - as said before, please consider turning this into a series of "hands on" articles.thanksFri, 08 Aug 2008 07:26:10 GMTMark F. Cookhttp://www.sqlservercentral.com/Forums/Topic548847-1149-1.aspxIs anyone else having issues with MySQL's documentation and addition/removal of features? Things like database renaming (added then removed), local file imports having to use the option -L (was optional, now required) ... It seems like each release, no matter how minor, means I have to re-learn everything. Scripts I save in 1 version fail when run against the next minor release. I realize things like the database renaming were better off removed as they did not work at all. But how about fixing instead of just removing!Also I would have to agree with performance issues, I have tables with 144 million rows, in MyISAM and the performance is worse than that of an MS Access DB!Overall MySQL is not my DB of choice - SQL Server, Oracle and Sybase are better in every aspect. But MySQL is free, so I guess its worth all my time re-writing scripts!?Fri, 08 Aug 2008 07:18:49 GMTbnordberghttp://www.sqlservercentral.com/Forums/Topic548847-1149-1.aspxWonderful Article. I hope you continue this into a "series" and delve deeper into SQL Server vs. MySQL, perhaps in writing code, Stored Object (SPs, Views, Functions, etc) and other day-to-day use comparisons.Keep up the good work! Fri, 08 Aug 2008 07:15:35 GMTFrancis Apelhttp://www.sqlservercentral.com/Forums/Topic548847-1149-1.aspxGreat Article! I currently migrated a couple of MSSQL 2000 db's to MySQL.Fri, 08 Aug 2008 06:41:54 GMTmhaarsmahttp://www.sqlservercentral.com/Forums/Topic548847-1149-1.aspxDitto on the thanks. This was a good intro.Note: Yes, you're right about the religious wars. Some people approach these discussions with a ferver that is a little disturbing...:crazy:Fri, 08 Aug 2008 06:26:13 GMTSomeguyhttp://www.sqlservercentral.com/Forums/Topic548847-1149-1.aspxKen,Thanks for the article. Very informative! MarkFri, 08 Aug 2008 04:21:06 GMTSuperDBA-207096