MySQL-ის GUI კლიენტები: Workbench, DBeaver თუ HeidiSQL

უმეტესობისთვის პასუხი DBeaver Community-ა: უფასოა, მუშაობს Windows-ზე, macOS-სა და Linux-ზე, MySQL 8.4-ს პრობლემების გარეშე უმკლავდება, და იგივე ინსტრუმენტი მოგვიანებით PostgreSQL-სა და SQL Server-ზეც იმუშავებს. HeidiSQL უფრო სწრაფი და მსუბუქი არჩევანია, თუ Windows-ზე ხარ და ძირითადად მონაცემებს ათვალიერებ და არედაქტირებ. MySQL Workbench Oracle-ის საკუთარი ინსტრუმენტია და ის უნდა აირჩიო, როცა მისი სქემის მოდელირება და query-ების ვიზუალური გეგმები გინდა, იმის ფასად, რომ დანარჩენებზე ნელი და ჭირვეულია. სამივე დისტანციურ MySQL სერვერს ერთი და იმავე ხუთი მონაცემით უკავშირდება - ჰოსტი, პორტი, მომხმარებელი, პაროლი და ბაზა - და ერთი და იმავე რამდენიმე მიზეზით ვარდება, რასაც ეს პოსტი განიხილავს თითოეულის გამართვასთან ერთად.

რა გჭირდება, სანამ რომელიმე კლიენტს გახსნი#

ყველა კლიენტი ერთსა და იმავეს ითხოვს. ჯერ ეს შეაგროვე:

გამოიყენე აპლიკაციის მომხმარებელი, ან უკეთესი - ცალკე ანგარიში, ადამიანებისთვის შექმნილი, და არა root. GUI ძალიან ადვილს ხდის DELETE-ის არასწორ ჩანართზე გაშვებას, და ანგარიში, რომელსაც მხოლოდ აპლიკაციის ბაზასთან აქვს წვდომა, ზღუდავს, რამდენის გაკეთება შეუძლია ერთ არასწორ დაწკაპუნებას. MySQL-ის მომხმარებლები და პრივილეგიები აჩვენებს, როგორ შექმნა მხოლოდ წაკითხვის ანგარიში დასათვალიერებლად, რაც სწორი ნაგულისხმევია ყველასთვის, ვისაც მხოლოდ ყურება სჭირდება.

MySQL 8.4-ის შესახებ სერვერის მხარის ორი ფაქტი წყვეტს, საერთოდ დაუკავშირდება თუ არა კლიენტი:

• ავთენტიფიკაცია. ანგარიშები caching_sha2_password-ს იყენებს. ძველი mysql_native_password plugin 8.4-ში ნაგულისხმევად გამორთულია. კლიენტი, რომელიც ძველ კლიენტურ ბიბლიოთეკაზეა აგებული - დაახლოებით ყველაფერი MySQL 8.0-ისაზე ძველი - ავთენტიფიკაციას ვერ გადის და ვარდება Authentication plugin 'caching_sha2_password' cannot be loaded-ით. აქ განხილული სამივე კლიენტის მიმდინარე ვერსიები მას მხარს უჭერს.
• TLS. სერვერი TLS-ს ნაგულისხმევად რთავს სერტიფიკატით, რომელსაც თავად აგენერირებს. კლიენტებს მისით დაშიფვრა შეუძლიათ, მაგრამ მისი შემოწმება საჯარო სასერტიფიკაციო ცენტრთან ვერ, სანამ სერვერის CA ფაილს არ მისცემ.

თუ შეგიძლია, კავშირი ჯერ ტერმინალიდან შეამოწმე. თუ mysql -h db.example.com -P 3306 -u app -p app მუშაობს, სერვერი და ქსელი წესრიგშია და ნებისმიერი GUI პრობლემა კლიენტის პარამეტრია. დისტანციურად MySQL-თან დაკავშირება ბრძანების ხაზის კლიენტსა და SSL რეჟიმებს დეტალურად განიხილავს.

თუ MySQL კლიენტი დაყენებული არ გაქვს, მაინც შეგიძლია შეამოწმო, საერთოდ მისაწვდომია თუ არა პორტი, რაც ქსელის პრობლემებს ანგარიშის პრობლემებისგან ჯერ კიდევ GUI-ის ჩართვამდე გამოყოფს:

# Windows PowerShellTest-NetConnection db.example.com -Port 3306# macOS and Linux$ nc -vz db.example.com 3306

TcpTestSucceeded : True Windows-ზე, ან succeeded / open nc-დან ნიშნავს, რომ რაღაც უსმენს და შენი ქსელი მასთან მისვლის საშუალებას გაძლევს. timeout ნიშნავს, რომ firewall ტრაფიკს აგდებს - ხშირად ოფისის ან სკოლის ქსელი, რომელიც უჩვეულო გამავალ პორტებს ბლოკავს - და კლიენტის არცერთი პარამეტრი არ დაგეხმარება. "Connection refused" ნიშნავს, რომ ჰოსტმა უპასუხა, მაგრამ ამ პორტზე არაფერი უსმენს, რაც თითქმის ყოველთვის არასწორ პორტის ნომერს ნიშნავს. როცა ეს ტესტი გაივლის, ნებისმიერი დარჩენილი ჩავარდნა კლიენტსა და თავად MySQL-ს შორისაა, და ქვემოთ შეცდომების ცხრილი მათ განიხილავს.

სამის შედარება#

სამიდან არცერთი არასწორი არ არის. არჩევანი სიგანეს (DBeaver), სიჩქარეს (HeidiSQL) ან MySQL-ის სპეციფიკურ სიღრმეს (Workbench) შორისაა. ბევრს საბოლოოდ ორი რჩება: HeidiSQL ან DBeaver ყოველდღიური სამუშაოსთვის და Workbench ღია დროდადრო ER დიაგრამისთვის ან გეგმისთვის.

DBeaver-ით დაკავშირება#

1. დააწკაპუნე plug-ის ხატულაზე პლიუსით (New Database Connection), აირჩიე MySQL და დააწკაპუნე Next.
2. Main ჩანართზე დააყენე Server Host, Port, Database, Username და Password. Authentication დატოვე Database Native-ზე. Save password მონიშნე მხოლოდ მანქანაზე, რომელსაც ენდობი.
3. დააწკაპუნე Test Connection. პირველად DBeaver შემოგთავაზებს MySQL JDBC დრაივერის (Connector/J) ჩამოტვირთვას; დაეთანხმე.
4. დააწკაპუნე Finish. კავშირი Database Navigator-ში გამოჩნდება.

DBeaver Java-ს დრაივერს იყენებს და არა MySQL-ის C ბიბლიოთეკას, და ამ დრაივერს აქვს ერთი შეცდომა, რომელსაც MySQL 8-ზე ყველა აწყდება: Public Key Retrieval is not allowed. caching_sha2_password-ით კლიენტს, რომელიც დაუშიფრავი კავშირით შედის, პაროლის უსაფრთხოდ გასაგზავნად სერვერის RSA საჯარო გასაღები სჭირდება, და Connector/J უარს ამბობს მის მოთხოვნაზე, სანამ არ უთხრეს. ორი გამოსავალი, Driver properties ჩანართზე:

• დაშიფრე კავშირი: დააყენე useSSL true-ზე (და requireSSL true-ზე, თუ დაჟინება გინდა). ამ შემთხვევაში პაროლი TLS-ის შიგნით მოგზაურობს და გასაღების მოთხოვნა საჭირო არ არის. ეს უკეთესი გამოსავალია.
• დაუშვი გასაღების მოთხოვნა: დააყენე allowPublicKeyRetrieval true-ზე. ეს მუშაობს, მაგრამ შუაში მყოფ მანქანას შეუძლია საკუთარი გასაღები მოგაწოდოს, ამიტომ ინტერნეტის გავლით TLS ამჯობინე.

useSSL=truerequireSSL=trueverifyServerCertificate=falseallowPublicKeyRetrieval=false

verifyServerCertificate=false შიფრავს იმის შემოწმების გარეშე, ვინ გიპასუხა, რაც თავად გენერირებული სერვერის სერტიფიკატის შემთხვევაში გაქვს. თუ სერვერის CA სერტიფიკატი გაქვს, ამის ნაცვლად გამოიყენე SSL ჩანართი, რომ მიაწოდო და შეამოწმო. SSH ჩანართი კავშირს გვირაბით ატარებს სერვერზე, რომელზეც shell წვდომა გაქვს, და ეს არის გზა ბაზამდე, რომელიც ინტერნეტზე გამოტანილი არ არის.

სასარგებლო ჩვევები DBeaver-ში: ცოცხალი ბაზებისთვის კავშირის ტიპი (Edit Connection, General) Production-ზე დააყენე, რაც რედაქტორს აფერადებს, რომ იცოდე, სად ხარ, და ბრძანებების გაშვებამდე დადასტურების მოთხოვნა შეუძლია; Ctrl+Enter კურსორის ქვეშ მყოფ ბრძანებას უშვებს, ხოლო Alt+X მთელ სკრიპტს; და შედეგების მაყურებელი ნაგულისხმევად 200 ხაზს ერთდროულად წამოიღებს, ასე რომ სწრაფად მოჩვენებულ query-ს შეიძლება ყველაფერი არ ჰქონდეს წამოღებული.

HeidiSQL-ით დაკავშირება#

1. გახსენი Session manager და დააწკაპუნე New, შემდეგ session-ს სახელი დაარქვი.
2. Network type დააყენე MySQL-ის ან MariaDB-ის TCP/IP ვარიანტზე.
3. შეავსე Hostname / IP, User, Password და Port. Databases ველი იღებს საჩვენებელი ბაზების წერტილმძიმით გამოყოფილ სიას; ცარიელი დატოვე, რომ ნახო ყველაფერი, რაზეც მომხმარებელს წვდომა აქვს.
4. დააწკაპუნე Open.

SSL ჩანართზე მონიშნე Use SSL session-ის დასაშიფრად და მიაწოდე CA სერტიფიკატი, თუ შემოწმებისთვის გაქვს. Advanced ჩანართი შეიცავს კლიენტურ ბიბლიოთეკას, რომელსაც HeidiSQL ტვირთავს. თუ session ვარდება caching_sha2_password cannot be loaded-ით, გადართე ეს ბიბლიოთეკა სიიდან MySQL 8-ის ან უფრო ახალ libmysql-ზე - ძველი ჩაშენებული ბიბლიოთეკები ამ plugin-ზე ადრეულია - ან თავად HeidiSQL განაახლე.

რაშიც HeidiSQL კარგია, ეს სიჩქარეა: ის მყისიერად იხსნება, ცხრილის მონაცემებს ადგილზე არედაქტირებს, და მის Tools მენიუში არის Export database as SQL, რომელიც არჩეული ცხრილების ან ბაზების dump-ს წერს ფაილში, სხვა სერვერზე ან clipboard-ში. დიდი ბაზისთვის ნამდვილი mysqldump მაინც უფრო უსაფრთხო backup-ია - იხილე mysqldump-ით backup და აღდგენა - მაგრამ სერვერებს შორის რამდენიმე ცხრილის დასაკოპირებლად HeidiSQL-ს ძნელად აჯობებ.

HeidiSQL ძირითადად Windows-ის პროგრამაა. ხალხი მას Linux-სა და macOS-ზე Wine-ით უშვებს არაერთგვაროვანი შედეგით; ამ სისტემებზე DBeaver გამოიყენე.

MySQL Workbench-ით დაკავშირება#

1. მთავარ ეკრანზე დააწკაპუნე პლიუსზე MySQL Connections-ის გვერდით.
2. მიეცი Connection Name, Connection Method დატოვე Standard (TCP/IP).
3. დააყენე Hostname, Port და Username. დააწკაპუნე Store in Vault (Windows, macOS) ან Store in Keychain (Linux) პაროლის შესანახად.
4. სურვილისამებრ Default Schema შენს ბაზაზე დააყენე.
5. SSL ჩანართზე Use SSL პარამეტრს ხუთი მნიშვნელობა აქვს: No, If available, Require, Require and Verify CA, Require and Verify Identity. დისტანციურ სერვერზე თავად გენერირებული სერტიფიკატით გამოიყენე Require; CA ფაილით - Require and Verify CA.
6. დააწკაპუნე Test Connection, შემდეგ OK.

Workbench-ს სამი ნაგულისხმევი პარამეტრი აქვს, რომლებიც ღირს იცოდე, სანამ გაგაკვირვებს:

სამივე მდებარეობს Edit, Preferences, SQL Editor-ში (და SQL Execution-ში ხაზების ლიმიტისთვის). Safe Updates-ის ჩართული დატოვება ღირს - შეცდომა 1175-მა ბევრი ცხრილი გადაარჩინა. read timeout ის არის, რომელიც უნდა გაზარდო, თუ Workbench-იდან გრძელ ანგარიშებს ან ALTER TABLE-ებს უშვებ; query წესრიგში იყო, Workbench-მა უბრალოდ ლოდინი შეწყვიტა.

სად იმსახურებს Workbench თავის ადგილს: Visual Explain query-ის შესრულების გეგმას ღირებულებებით ხატავს, რაც გეგმების კითხვის სასწავლად კარგი გზაა (იხილე MySQL-ის index-ები და EXPLAIN); Database, Reverse Engineer ცოცხალი სქემიდან ER დიაგრამას აგებს; ხოლო Users and Privileges ეკრანი grant-ების წაკითხვადი ხედია. მისი Data Export ჩაშენებულ mysqldump-ს უშვებს, რომელიც სერვერზე ძველი არ უნდა იყოს - იქ ვერსიების შეუსაბამობის გაფრთხილება ყურადღების ღირსია.

Workbench-ის ზოგიერთი გამოშვება აჩვენებს გაფრთხილებას შეუთავსებელი ან არასტანდარტული სერვერის ვერსიის შესახებ, როცა უფრო ახალ სერვერს უკავშირდება, ვიდრე ის, რომელზეც გატესტილია. ეს გაფრთხილებაა; შეგიძლია გააგრძელო, და ყოველდღიური query-ები მუშაობს.

შეცდომები, რომლებიც ყველა კლიენტს აჩერებს#

კლიენტი იცვლება; მიზეზები - არა.

შეცდომა 2003 და 1045 შორის განსხვავება ამ ცხრილში ყველაზე სასარგებლოა. 2003 ნიშნავს, რომ MySQL-მდე საერთოდ ვერ მიხვედი - ქსელის პრობლემა. 1045 ნიშნავს, რომ MySQL-მა გიპასუხა და უარი გითხრა - ანგარიშის პრობლემა. ანგარიშის მხარე ახსნილია MySQL-ის მომხმარებლებსა და პრივილეგიებში: MySQL ანგარიშს მომხმარებლის სახელითა და კლიენტის ჰოსტით ერთად ამოიცნობს, ამიტომ 'app'@'localhost' შენი ლეპტოპიდან ვერ შევა, რაც არ უნდა სწორი იყოს მისი პაროლი.

GUI-დან უსაფრთხოდ მუშაობა#

გრაფიკული კლიენტი მხოლოდ მოხერხებულობას კი არა, რისკსაც ცვლის. რამდენიმე ჩვევა შემთხვევების უმეტესობას აცილებს:

• ცალკე კავშირები production-ისა და ყველაფერი დანარჩენისთვის, სხვადასხვანაირად დასახელებული და შეფერილი. "არასწორ ბაზაზე გავუშვი" ისტორიების უმეტესობაში ორი ჩანართია, რომლებიც ერთნაირად გამოიყურებოდა.
• autocommit-ს მიხედე. სამივე კლიენტი ნაგულისხმევად autocommit-ზეა, მაგრამ სამივე გაძლევს ხელით commit-ზე გადართვის საშუალებას. ხელით რეჟიმში ყოველი UPDATE, რომელსაც უშვებ, თავის row lock-ებს ინარჩუნებს, სანამ Commit-ს არ დააწკაპუნებ - და აპლიკაცია შენს უკან ელოდება. GUI-ში დავიწყებული commit-ის გარეშე დარჩენილი რედაქტირება lock wait timeout-ების კლასიკური მიზეზია; MySQL-ის ტრანზაქციები, locking და deadlock-ები აჩვენებს, როგორ იპოვო.
• ცხრილში რედაქტირება SQL-ია. უჯრის რედაქტირება და შენახვა უშვებს UPDATE-ს WHERE-ით, რომელიც primary key-დან აიგება. primary key-ის გარეშე ცხრილზე ზოგი კლიენტი WHERE-ს ყველა სვეტიდან აგებს, და დუბლირებული ხაზი ნიშნავს, რომ ერთი რედაქტირება ორ ხაზს ცვლის. ყოველ ცხრილს primary key მიეცი.
• დიდი შედეგები შენი მანქანის მეხსიერებაში ცხოვრობს. SELECT * FROM events ორმოცდაათ მილიონ ხაზზე კლიენტს შეიძლება გაყინავს მანამდე დიდი ხნით ადრე, სანამ სერვერს რამე ეწყინება. დათვალიერებისას LIMIT დაამატე.
• დახურე ის, რასაც არ იყენებ. ყოველ ღია ჩანართს შეიძლება კავშირი ეჭიროს, და უმოქმედო GUI session-ები max_connections-ში ითვლება, როგორც ყველაფერი სხვა.

სხვა კლიენტები, რომლებიც ღირს იცოდე#

ზემოთ ჩამოთვლილი სამი ერთადერთი ვარიანტი არ არის:

• mysql და MySQL Shell (`mysqlsh`) - ბრძანების ხაზის კლიენტები. ყოველთვის ხელმისაწვდომი, სკრიპტებით მართვადი და ეტალონი იმის გასარკვევად, კავშირის პრობლემა სერვერისაა თუ GUI-ის.
• Sequel Ace - უფასო, ღია კოდით, მხოლოდ macOS, MySQL და MariaDB. ბუნებრივი არჩევანი Mac-ზე, თუ DBeaver მძიმედ მიგაჩნია.
• TablePlus - ნატიური, სწრაფი, მრავალბაზიანი, კომერციული შეზღუდული უფასო ვერსიით.
• DataGrip - JetBrains-ის ფასიანი ბაზების IDE, ყველაზე კარგი SQL-ის ავტოდასრულებით მათ შორის. ასევე ჩაშენებულია მათ სხვა IDE-ებში ბაზების ინსტრუმენტის ფანჯრად.
• Beekeeper Studio - ღია კოდით, მრავალპლატფორმული, მარტივი; კომერციული გამოცემა შესაძლებლობებს ამატებს.
• phpMyAdmin და Adminer - ვებზე დაფუძნებული, PHP ჰოსტზე გაშვებული. სასარგებლოა, როცა ლოკალურად ვერაფერს დააყენებ; ისინი ვებ სერვერიდან უკავშირდება და არა შენი მანქანიდან. phpMyAdmin-ის იმპორტისა და ექსპორტის გზამკვლევი იმპორტის მხარეს განიხილავს.

FAQ#

შემიძლია MySQL Workbench MariaDB-სთან გამოვიყენო?

ხშირად უკავშირდება, მაგრამ Workbench MySQL-ისთვისაა აგებული და ზოგი ეკრანი MariaDB-ზე არასწორ ინფორმაციას აჩვენებს ან ტყდება, რადგან ეს ორი ერთმანეთს დაშორდა. HeidiSQL და DBeaver MariaDB-ს სრულფასოვან სამიზნედ ეპყრობიან. MySQL 8.4 სერვერისთვის სამივე კარგია.

რატომ უკავშირდება კლიენტი სახლიდან, მაგრამ არა ოფისიდან?

ან ოფისის ქსელი ბლოკავს გამავალ კავშირებს ამ პორტზე, ან ბაზის ანგარიში ან firewall მხოლოდ გარკვეულ მისამართებს უშვებს. შეცდომა 2003 ქსელზე მიუთითებს; შეცდომა 1045 ან 1130 ოფისის მისამართით - ანგარიშის ჰოსტის შაბლონზე.

უსაფრთხოა პაროლის კლიენტში შენახვა?

შენს საკუთარ დაშიფრულ მანქანაზე - საკმაოდ. Workbench მას ოპერაციული სისტემის keychain-ში ინახავს; DBeaver და HeidiSQL საკუთარ კონფიგურაციაში, რომელიც ნაკლებად დაცულია. production-ისთვის განიხილე, რომ არ შეინახო, ან შენახული კავშირისთვის მხოლოდ წაკითხვის ანგარიში გამოიყენო.

მჭირდება TLS, თუ ინტერნეტით ვუკავშირდები?

კი. მის გარეშე ყოველი query და შედეგი ქსელს უბრალო ტექსტად კვეთს, და ძველი ავთენტიფიკაციის გზებზე - მონაცემებიც. სამივე კლიენტი TLS-ს უჭერს მხარს; მისი ჩართვა ერთი პარამეტრია.

რომელი კლიენტია საუკეთესო დიდი SQL dump-ის იმპორტისთვის?

არცერთი. GUI იმპორტები ფაილს კლიენტის გავლით ტვირთავენ და რამდენიმე ასეულ მეგაბაიტზე დიდ dump-ებზე ნელია ან ვარდება. გამოიყენე ბრძანების ხაზის კლიენტი: mysql -h host -P port -u user -p dbname < dump.sql.