Відмінності між MySQL та SQL сервером [закрито]

Я розробник ASP.NET, який використовував Microsoft SQL Serverдля всіх потреб моєї бази даних (як на роботі, так і для особистих проектів).

Я розглядаю можливість випробувати стек LAMP для деяких моїх особистих проектів.

Які основні відмінності між MySQLта SQL Server? Чи є використання збережених процедур поширеною практикою MySQL?

Будь-яка порада чи ресурси, які ви рекомендуєте, щоб допомогти мені перейти?

Тим, хто має досвід роботи з обома, чи є якісь відсутні функції MySQL?

Одне, на що потрібно стежити, - це досить серйозні відмінності в способі реалізації SQL Server та MySQL синтаксису SQL.

Ось приємне порівняння різних реалізацій SQL .

Наприклад, погляньте на верхній-розділ. У MySQL:

SELECT age
FROM person
ORDER BY age ASC
LIMIT 1 OFFSET 2

У SQL Server (T-SQL):

SELECT TOP 3 WITH TIES *
FROM person
ORDER BY age ASC

Багато коментарів тут звучать більше як релігійні аргументи, ніж твердження реального життя. Я роками працював і з MySQL, і з MSSQL, і обидва - хороші продукти. Я б вибрав MySQL в основному на основі середовища, над яким ви працюєте. Більшість проектів з відкритим кодом використовують MySQL, тому якщо ви йдете в цьому напрямку, MySQL - це ваш вибір. Якщо ви розробляєте щось з .Net, я б вибрав MSSQL не тому, що це набагато краще, а просто тому, що саме цим користується більшість людей. Зараз я фактично працюю над проектом, який використовує ASP.NET з MySQL та C #. Це прекрасно працює.

Я не можу повірити, що ніхто не згадував, що MySQL не підтримує загальні вирази таблиць (CTE) / "з". Це досить дратівлива різниця.

У MySQL більше шансів виникнути проблеми з корупцією баз даних, і вони не виправляють їх автоматично, коли вони трапляються. Я працював з MSSQL з версії 6.5 і не пам’ятаю проблеми з пошкодженням бази даних, яка знімає базу даних в автономному режимі. Кілька разів, коли я працював з MySQL у виробничому середовищі, проблема з пошкодженням бази даних зайняла всю базу даних в режимі офлайн, поки ми не запустили магічну штучку "виправити мій пошкоджений індекс" із командного рядка.

Система транзакцій та журналів MSSQL, на мій досвід, обробляє практично все, включаючи цикл живлення або збій обладнання - без пошкодження бази даних, і якщо щось зіпсується, вона виправляє це автоматично.

Це був мій досвід, і я був би радий почути, що це було виправлено чи ми щось робили не так.

http://dev.mysql.com/doc/refman/6.0/en/corrupted-myisam-tables.html

http://www.google.com/search?q=site%3Abugs.mysql.com+index+corption

Чесно кажучи, я не можу знайти жодної причини використовувати MySQL, а не MSSQL. Проблема, яка раніше була вартістю, але SQL Server 2005 Express безкоштовна, і є безліч веб-хостингових компаній, які пропонують повний хостинг з sql-сервером менше ніж за 5,00 доларів на місяць.

MSSQL простіший у використанні та має багато функцій, яких не існує в MySQL.

Здається, все в MySQL робиться ближче до металу, ніж у MSSQL, і документація так трактує. Спеціально для оптимізації вам потрібно зрозуміти, як індекси, конфігурація системи та оптимізатор взаємодіють за різних обставин.

"Оптимізатор" - це більше аналіз. У MSSQL ваш план запитів часто є сюрпризом (як правило, хорошим, іноді ні). У MySQL він значною мірою робить те, що ви просили, так, як ви цього і очікували. Це означає, що ви самі повинні глибоко розуміти різні способи, як це можна зробити.

Не побудовано навколо хорошої моделі TRANSACTION (двигун MyISAM за замовчуванням).

Ваша проблема - налаштування файлової системи.

Вся конфігурація бази даних - ваша проблема - особливо різні розміри кешу.

Іноді здається, що найкраще думати про це як про спеціальний прославлений ізам. Codd і Date не мають великої ваги тут. Вони б сказали це без сором.

Я думаю, що однією з головних речей, на яку слід звернути увагу, є те, що версії до MySQL 5.0 не мали переглядів, тригерів та збережених процедур.

Більше цього пояснено на сторінці завантаження MySQL 5.0 .

@abdu

Головне, що я виявив, що MySQL має більше MSSQL, - це підтримка часового поясу - можливість красиво змінюватися між часовими поясами, зважаючи на економію денного світла, є фантастичною.

Порівняйте це:

mysql> SELECT CONVERT_TZ('2008-04-01 12:00:00', 'UTC', 'America/Los_Angeles');
+-----------------------------------------------------------------+
| CONVERT_TZ('2008-04-01 12:00:00', 'UTC', 'America/Los_Angeles') |
+-----------------------------------------------------------------+
| 2008-04-01 05:00:00                                             |
+-----------------------------------------------------------------+

до суперечок, пов'язаних з цією відповіддю .

Що стосується коментаря "простіший у використанні", я б сказав, що справа в тому, що вони різні, і якщо ви знаєте одне, то буде вивчати інше.

Обидва - сервер Product Sql DBMS - комерційна програма, в той час як MySql - це програма openouces. Але продукт включає подібну функцію, однак сервер sql повинен використовуватися для корпоративного рішення, тоді як mysql може відповідати меншій реалізації. Якщо вам потрібна така функція, як відновлення, реплікація, гранальна безпека та важливе значення, вам потрібен сервер sql

MySql займає менше місця на диску і використовує менше пам'яті та процесора, ніж сервер sql

Хтось має хороший досвід роботи з «портом» бази даних від SQL Server до MySQL?

Це має бути досить болісно! Я перемикав версії MySQL з 4.x на 5.x, і різні заяви більше не працюватимуть, як раніше. Аналізатор запитів був «покращений», тому твердження, які раніше були налаштовані на ефективність, більше не працюватимуть, як очікувалося.

Урок, отриманий з роботи з базою даних MySQL на 500 ГБ: Це тонка тема і все інше, окрім дрібниці!

@Cebjyre. IDE, будь то Enterprise Manager або Management Studio, кращий за все, що я бачив для MySQL. Я кажу "простіше у використанні", оскільки я можу робити багато речей у MSSQL, де MySQL не має аналогів. У MySQL я не маю уявлення, як настроїти запити, просто переглянувши план запитів або переглянувши статистику. Майстер настройки індексу в MSSQL займає більшу частину роботи з здогадів щодо того, які індекси відсутні чи неправильно розміщені.

Одним із недоліків MySQL є відсутність максимального розміру для бази даних. База даних просто збільшиться в розмірі, поки вона не заповнить диск. Уявіть, якщо цей диск обмінюється базами даних з іншими користувачами і раптом усі їх запити не вдається, оскільки їхні бази даних не можуть рости. Я давно повідомляв про цю проблему в MySQL. Я не думаю, що це ще виправлено.

Провівши деякий час, працюючи з MySQL від MSSQL до синтаксису MySQL POV, я обмежився тим, що міг би зробити.

Існують обмеження щодо оновлення таблиці під час оновлення цієї ж таблиці під час оновлення.

Крім того, ОНОВЛЕННЯ ВІД не працює, і я востаннє перевіряв, що вони не підтримують синтаксис Oracle MERGE INTO. Це була пробка для шоу, і я перестала думати, що після цього я дістанусь кудись із MySQL.