ALTER TABLE mà không cần khóa bảng?


107

Khi thực hiện một câu lệnh ALTER TABLE trong MySQL, toàn bộ bảng được khóa đọc (cho phép đọc đồng thời, nhưng cấm ghi đồng thời) trong suốt thời gian của câu lệnh. Nếu đó là một bảng lớn, các câu lệnh INSERT hoặc UPDATE có thể bị chặn trong một thời gian dài. Có cách nào để thực hiện "thay đổi nóng", như thêm một cột theo cách mà bảng vẫn có thể cập nhật trong suốt quá trình không?

Chủ yếu là tôi quan tâm đến một giải pháp cho MySQL nhưng tôi muốn quan tâm đến các RDBMS khác nếu MySQL không thể làm điều đó.

Để làm rõ, mục đích của tôi chỉ đơn giản là để tránh thời gian chết khi một tính năng mới yêu cầu cột bảng bổ sung được đẩy sang phiên bản sản xuất. Bất kỳ lược đồ cơ sở dữ liệu nào cũng sẽ thay đổi theo thời gian, đó chỉ là một thực tế của cuộc sống. Tôi không hiểu tại sao chúng ta nên chấp nhận rằng những thay đổi này chắc chắn phải dẫn đến thời gian ngừng hoạt động; đó chỉ là yếu.


2
Bạn phải tự hỏi bao nhiêu lần bạn sẽ thay đổi bảng?
Allain Lalonde

1
IMHO, các thay đổi lược đồ cơ sở dữ liệu được liên kết với các phiên bản hoàn toàn mới - chúng không được triển khai thường xuyên như các thay đổi khác. Đó chắc chắn là một vấn đề lớn.
dkretz

9
@AllainLalonde - hơn 0 lần câu hỏi này là hợp pháp, đặc biệt là nếu thời gian ngừng hoạt động trong hệ thống của bạn sẽ khiến bạn phải trả giá bằng mạng sống hoặc rất nhiều tiền. Và ở bất kỳ mức độ nào, các yêu cầu phần mềm mới đôi khi xuất hiện.
Nathan Long

Câu trả lời:


60

Tùy chọn khác duy nhất là làm theo cách thủ công những gì nhiều hệ thống RDBMS vẫn làm ...
- Tạo một bảng mới

Sau đó, bạn có thể sao chép nội dung của bảng cũ qua một đoạn nhỏ tại một thời điểm. Trong khi luôn thận trọng với bất kỳ CHÈN / CẬP NHẬT / XÓA nào trên bảng nguồn. (Có thể được quản lý bởi một trình kích hoạt. Mặc dù điều này sẽ gây ra sự chậm lại, nhưng nó không phải là một khóa ...)

Sau khi hoàn tất, hãy thay đổi tên của bảng nguồn, sau đó đổi tên của bảng mới. Tốt nhất là trong một giao dịch.

Sau khi hoàn tất, hãy biên dịch lại mọi thủ tục được lưu trữ, v.v. sử dụng bảng đó. Các kế hoạch thực hiện có thể sẽ không còn hiệu lực.

BIÊN TẬP:

Một số nhận xét đã được đưa ra về hạn chế này là một chút kém. Vì vậy, tôi nghĩ tôi sẽ đặt một góc nhìn mới về nó để cho thấy lý do tại sao nó như thế nào ...

  • Thêm trường mới giống như thay đổi một trường trên mỗi hàng.
  • Khóa Trường sẽ khó hơn nhiều so với Khóa hàng, đừng bận tâm đến khóa bảng.

  • Bạn đang thực sự thay đổi cấu trúc vật lý trên đĩa, mọi bản ghi sẽ di chuyển.
  • Đây thực sự giống như một CẬP NHẬT trên Toàn bộ bảng, nhưng có nhiều tác động hơn ...

2
Và có kế hoạch kiểm tra kỹ lưỡng trước khi hoán đổi. Nếu nó không thành công, hãy bắt đầu lại.
dkretz

2
Quản lý đồng bộ hóa thông qua các trình kích hoạt là một ý tưởng hay. Tôi đã sử dụng MySQL quá lâu nên giờ vẫn quên rằng chúng có các trình kích hoạt. Tôi đã sử dụng kỹ thuật này và bây giờ tôi có một tập lệnh thay đổi nóng chức năng. Với một thanh tiến trình. Và nó hoạt động với MyISAM. Cuộc sống là tốt.
Daniel

2
+1 Đây thực sự là những gì người quản lý SQL Enterprise thực hiện đằng sau hậu trường khi bạn thực hiện một số loại thay đổi bảng trong giao diện người dùng. Trong SQL 2008, họ đã thực sự thêm một cảnh báo để người dùng BIẾT nó thực hiện hành động quyết liệt này.
BradC

2
Bạn đã không đề cập bất cứ điều gì về khóa ngoại tham chiếu đến các bảng đang được thay đổi. Đó sẽ không phải là một vấn đề?
Rafay

2
@MohammadRafayAleem - Và các trường AUTOINCREMENT, chế độ xem và trình kích hoạt, v.v. Nhưng ngay cả như vậy, phương pháp này vẫn khả thi.
MatBailie

42

Percona tạo ra một công cụ có tên là pt-online-schema-change cho phép thực hiện điều này.

Về cơ bản, nó tạo một bản sao của bảng và sửa đổi bảng mới. Để giữ cho bảng mới đồng bộ với bảng gốc, nó sử dụng trình kích hoạt để cập nhật. Điều này cho phép truy cập bảng gốc trong khi bảng mới được chuẩn bị trong nền.

Điều này tương tự như phương pháp Dems đề xuất ở trên, nhưng điều này làm như vậy theo cách tự động.

Một số công cụ của họ có một đường cong học tập, cụ thể là kết nối với cơ sở dữ liệu, nhưng một khi bạn có điều đó, chúng là những công cụ tuyệt vời để có.

Ví dụ:

pt-online-schema-change --alter "ADD COLUMN c1 INT" D=db,t=numbers_are_friends

Có vẻ như liên kết bị hỏng. Tôi thấy liên kết này đang hoạt động.
Noam Ben Ari

25

Câu hỏi này từ năm 2009. Bây giờ MySQL đưa ra một giải pháp:

DDL trực tuyến (Ngôn ngữ định nghĩa dữ liệu)

Một tính năng cải thiện hiệu suất, đồng thời và tính khả dụng của các bảng InnoDB trong các hoạt động DDL (chủ yếu là ALTER TABLE). Xem Phần 14.11, “InnoDB và DDL Trực tuyến” để biết chi tiết.

Các chi tiết thay đổi tùy theo loại hoạt động. Trong một số trường hợp, bảng có thể được sửa đổi đồng thời khi đang tiến hành ALTER TABLE. Thao tác này có thể được thực hiện mà không cần sao chép bảng hoặc sử dụng một loại sao chép bảng được tối ưu hóa đặc biệt. Việc sử dụng dung lượng được kiểm soát bởi tùy chọn cấu hình innodb_online_alter_log_max_size.

Nó cho phép bạn điều chỉnh sự cân bằng giữa hiệu suất và đồng thời trong quá trình hoạt động DDL, bằng cách chọn chặn toàn bộ quyền truy cập vào bảng (mệnh đề LOCK = EXCLUSIVE), cho phép truy vấn nhưng không cho phép DML (mệnh đề LOCK = SHARED) hay cho phép truy vấn đầy đủ và DML truy cập vào bảng (mệnh đề LOCK = NONE). Khi bạn bỏ qua mệnh đề LOCK hoặc chỉ định LOCK = DEFAULT, MySQL cho phép nhiều đồng thời nhất có thể tùy thuộc vào loại hoạt động.

Thực hiện các thay đổi tại chỗ nếu có thể, thay vì tạo một bản sao mới của bảng, tránh tăng tạm thời việc sử dụng không gian đĩa và chi phí I / O liên quan đến việc sao chép bảng và tạo lại các chỉ mục phụ.

xem Hướng dẫn tham khảo MySQL 5.6 -> InnoDB và DDL Trực tuyến để biết thêm thông tin.

Có vẻ như DDL trực tuyến cũng có sẵn trong MariaDB

Ngoài ra, bạn có thể sử dụng ALTER ONLINE TABLE để đảm bảo rằng ALTER TABLE của bạn không chặn các hoạt động đồng thời (không có khóa). Nó tương đương với LOCK = NONE.

MariaDB KB về ALTER TABLE


3
Thật tiếc là không có cách nào khác ngoài phiếu bầu để đưa câu trả lời này lên đầu, vì nó chủ yếu phủ nhận tất cả các câu trả lời khác hoàn toàn vì chúng không còn tham chiếu đến phiên bản MySQL hiện tại.
Burhan Ali


14

Tôi khuyên bạn nên Postgres nếu đó là một lựa chọn. Với postgres về cơ bản không có thời gian chết với các thủ tục sau:

Một tính năng tuyệt vời khác là hầu hết các câu lệnh DDL đều có tính chất giao dịch, vì vậy bạn có thể thực hiện toàn bộ quá trình di chuyển trong một giao dịch SQL và nếu có sự cố xảy ra, toàn bộ mọi thứ sẽ được khôi phục lại.

Tôi đã viết điều này một chút trước đây, có lẽ nó có thể làm sáng tỏ thêm một số cái nhìn sâu sắc hơn về những giá trị khác.


6
Postgres vẫn tạo một khóa độc quyền trên bảng thay đổi, ngăn người khác đọc từ bảng đó.
clofresh vào

5
Tôi không đồng ý với bit "về cơ bản không có thời gian chết". Như clofresh đã nói, ALTER TABLE lấy một khóa độc quyền trên bảng chặn tất cả các lần đọc và ghi đồng thời. Theo kinh nghiệm của tôi, đối với các bảng đang hoạt động, hầu hết các lần bạn thậm chí sẽ không nhận được khóa (ALTER TABLE sẽ chết đói). Và với các giao dịch, bạn có thể dễ dàng gặp bế tắc nếu không cực kỳ cẩn thận. Do đó, bây giờ tôi luôn đặt thời gian chết khi thay đổi các bảng hiện có trong Postgres.
Pankrat

1
một lời giải thích chi tiết hơn: dba.stackexchange.com/questions/27153/... nó đề cập đến ý nghĩa của khóa độc quyền, và một số cách để làm việc xung quanh nó
John Douthat

4
Có, việc thay đổi một bảng trong postgres lấy một khóa độc quyền, nhưng vì hoạt động tự hoàn thành trong mili giây nên thực tế không liên quan trong hầu hết các trường hợp. Cá nhân tôi đã thêm các cột vào bảng hàng trăm triệu hàng vào giữa ngày làm việc mà không có thời gian ngừng hoạt động.
Noah Yetter

2
@cobbzilla Có, DROP COLUMN cũng nhanh như vậy. Về cơ bản, những gì nó làm là đánh dấu cột là ẩn. Các giá trị tồn tại trong cột đó trước đó đã bị loại bỏ vẫn còn trong tệp dữ liệu (và hiển thị với các giao dịch khác) và sẽ vẫn như vậy trừ khi và cho đến khi bạn thực hiện ĐẦY ĐỦ VACUUM.
Noah Yetter

7

Vì bạn đã hỏi về các cơ sở dữ liệu khác, đây là một số thông tin về Oracle.

Thêm cột NULL vào bảng Oracle là một thao tác rất nhanh chóng vì nó chỉ cập nhật từ điển dữ liệu. Điều này giữ một ổ khóa độc quyền trên bàn trong một khoảng thời gian rất ngắn. Tuy nhiên, nó sẽ làm mất hiệu lực của bất kỳ thủ tục, khung nhìn, trình kích hoạt nào được lưu trữ, v.v ... Chúng sẽ được biên dịch lại tự động.

Từ đó, nếu cần, bạn có thể tạo chỉ mục bằng mệnh đề ONLINE. Một lần nữa, chỉ khóa từ điển dữ liệu rất ngắn. Nó sẽ đọc toàn bộ bảng để tìm kiếm những thứ cần lập chỉ mục, nhưng không chặn bất kỳ ai khi thực hiện việc này.

Nếu bạn cần thêm khóa ngoại, bạn có thể thực hiện việc này và yêu cầu Oracle tin tưởng rằng dữ liệu là chính xác. Nếu không, nó cần đọc toàn bộ bảng và xác thực tất cả các giá trị có thể chậm (tạo chỉ mục của bạn trước).

Nếu bạn cần đặt một giá trị mặc định hoặc được tính toán vào mỗi hàng của cột mới, bạn sẽ cần chạy một bản cập nhật lớn hoặc có lẽ là một chương trình tiện ích nhỏ để điền dữ liệu mới. Điều này có thể chậm, đặc biệt nếu các hàng trở nên lớn hơn rất nhiều và không còn vừa với khối của chúng. Khóa có thể được quản lý trong quá trình này. Vì phiên bản cũ của ứng dụng của bạn, vẫn đang chạy, không biết về cột này, bạn có thể cần một trình kích hoạt lén lút hoặc để chỉ định một mặc định.

Từ đó, bạn có thể thực hiện chuyển đổi trên các máy chủ ứng dụng của mình sang phiên bản mới của mã và nó sẽ tiếp tục chạy. Bỏ kích hoạt lén lút của bạn.

Ngoài ra, bạn có thể sử dụng DBMS_REDEFINITION, một hộp đen được thiết kế để thực hiện loại điều này.

Tất cả những điều này khiến bạn phải bận tâm nhiều đến việc kiểm tra, v.v ... đến nỗi chúng tôi chỉ bị ngừng hoạt động vào sáng sớm Chủ nhật bất cứ khi nào chúng tôi phát hành một phiên bản chính.


3

Nếu bạn không thể dành thời gian ngừng hoạt động cho cơ sở dữ liệu của mình khi cập nhật ứng dụng, bạn nên cân nhắc duy trì một cụm hai nút để có tính khả dụng cao. Với một thiết lập sao chép đơn giản, bạn có thể thực hiện các thay đổi cấu trúc gần như hoàn toàn trực tuyến như cách bạn đề xuất:

  • đợi tất cả các thay đổi được lặp lại trên một nô lệ thụ động
  • thay đổi nô lệ thụ động thành chủ động
  • thực hiện các thay đổi cấu trúc đối với cái cũ
  • sao chép các thay đổi từ trang cái mới sang cái cũ
  • thực hiện lại việc hoán đổi chính và triển khai ứng dụng mới đồng thời

Nó không phải lúc nào cũng dễ dàng nhưng nó hoạt động, thường là với 0 thời gian chết! Nút thứ hai không nhất thiết phải là một nút thụ động, nó có thể được sử dụng để kiểm tra, thống kê hoặc làm nút dự phòng. Nếu bạn không có cơ sở hạ tầng, bản sao có thể được thiết lập trong một máy duy nhất (với hai phiên bản MySQL).


1
Chủ cũ nằm ngoài cụm hay trong cụm?
John Chornelius

2

Không. Nếu bạn đang sử dụng bảng MyISAM, theo sự hiểu biết tốt nhất của tôi, họ chỉ thực hiện khóa bảng - không có khóa bản ghi, họ chỉ cố gắng giữ mọi thứ siêu nhanh thông qua sự đơn giản. (Các bảng MySQL khác hoạt động khác nhau.) Trong bất kỳ trường hợp nào, bạn có thể sao chép bảng này sang một bảng khác, thay đổi nó, sau đó chuyển đổi chúng, cập nhật các điểm khác biệt.

Đây là một sự thay đổi lớn đến mức tôi nghi ngờ có bất kỳ DBMS nào sẽ hỗ trợ nó. Nó được coi là một lợi ích khi có thể làm điều đó với dữ liệu trong bảng ngay từ đầu.



Vâng, MySQL là một quang sai. Đó là lý do tại sao tôi đã nói cụ thể về các bảng "tiêu chuẩn".
dkretz

Bạn đã viết - các bảng MySQL tiêu chuẩn chỉ thực hiện khóa bảng - điều này không chính xác.
Eran Galperin

Làm thế nào để bạn giải thích điều này về các bảng MyISAM (tức là chuẩn MySQL) từ trang bạn đã trích dẫn? "MySQL sử dụng khóa cấp bảng cho các bảng MyISAM và MEMORY, khóa cấp trang cho các bảng BDB và khóa cấp hàng cho các bảng InnoDB."
dkretz

một số công cụ lưu trữ sử dụng khóa mức hàng và một số sử dụng khóa mức bảng. Không có công cụ lưu trữ tiêu chuẩn (có lẽ bạn có nghĩa là mặc định trong phpMyAdmin ...)
Eran Galperin

2

Giải pháp tạm thời...

Giải pháp khác có thể là, thêm một bảng khác có khóa chính của bảng gốc, cùng với cột mới của bạn.

Điền khóa chính của bạn vào bảng mới và điền các giá trị cho cột mới trong bảng mới, đồng thời sửa đổi truy vấn của bạn để tham gia bảng này cho các thao tác chọn và bạn cũng cần chèn, cập nhật riêng cho giá trị cột này.

Khi bạn có thể nhận được thời gian chết, bạn có thể thay đổi bảng gốc, sửa đổi các truy vấn DML và thả bảng mới đã tạo trước đó

Nếu không, bạn có thể sử dụng phương pháp phân cụm, sao chép, công cụ pt-online-schema từ percona


1

Sử dụng plugin Innodb, các câu lệnh ALTER TABLE chỉ thêm hoặc bớt chỉ mục phụ có thể được thực hiện "nhanh chóng", tức là không cần xây dựng lại bảng.

Tuy nhiên, nói chung trong MySQL, bất kỳ ALTER TABLE nào đều liên quan đến việc xây dựng lại toàn bộ bảng có thể mất một thời gian rất dài (tức là nếu bảng có một lượng dữ liệu hữu ích trong đó).

Bạn thực sự cần thiết kế ứng dụng của mình để các câu lệnh ALTER TABLE không cần được thực hiện thường xuyên; bạn chắc chắn không muốn bất kỳ BẢNG ALTER nào được thực hiện trong quá trình chạy bình thường của ứng dụng trừ khi bạn chuẩn bị chờ đợi hoặc bạn đang thay đổi các bảng nhỏ.


1

Tôi muốn giới thiệu một trong hai cách tiếp cận:

  1. Thiết kế các bảng cơ sở dữ liệu của bạn với những thay đổi tiềm năng trong tâm trí. Ví dụ: tôi đã làm việc với Hệ thống quản lý nội dung, hệ thống này thường xuyên thay đổi các trường dữ liệu trong nội dung. Thay vì xây dựng cấu trúc cơ sở dữ liệu vật lý để phù hợp với các yêu cầu ban đầu của trường CMS, tốt hơn nhiều là bạn nên xây dựng theo cấu trúc linh hoạt. Trong trường hợp này, sử dụng trường văn bản blob (ví dụ: varchar (max)) để chứa dữ liệu XML linh hoạt. Điều này làm cho việc thay đổi cấu trúc ít thường xuyên hơn. Thay đổi cấu trúc có thể tốn kém, vì vậy chi phí ở đây cũng có lợi.

  2. Có thời gian bảo trì hệ thống. Hệ thống sẽ ngoại tuyến trong thời gian thay đổi (hàng tháng, v.v.) và các thay đổi được lên lịch trong thời gian ít được buôn bán nhất trong ngày (ví dụ: 3-5 giờ sáng). Các thay đổi được tổ chức trước khi triển khai sản xuất, vì vậy bạn sẽ có ước tính thời gian ngừng hoạt động cố định tốt.

2a. Có các máy chủ dự phòng, để khi hệ thống có thời gian ngừng hoạt động, toàn bộ trang web không bị sập. Điều này sẽ cho phép bạn "tung" các bản cập nhật của mình ra theo kiểu so le mà không cần gỡ bỏ toàn bộ trang web.

Phương án 2 và 2a có thể không khả thi; chúng có xu hướng chỉ dành cho các trang web / hoạt động lớn hơn. Tuy nhiên, chúng là các tùy chọn hợp lệ và cá nhân tôi đã sử dụng tất cả các tùy chọn được trình bày ở đây.


1

Nếu ai đó vẫn đang đọc nó hoặc tình cờ đến đây, thì đây là lợi ích lớn của việc sử dụng hệ thống cơ sở dữ liệu NoSQL như mongodb. Tôi đã gặp vấn đề tương tự khi xử lý việc thay đổi bảng để thêm các cột cho các tính năng hoặc chỉ mục bổ sung trên một bảng lớn với hàng triệu hàng và số lần ghi cao. Nó sẽ bị khóa trong một thời gian rất dài, vì vậy việc làm này trên cơ sở dữ liệu TRỰC TIẾP sẽ khiến người dùng của chúng tôi thất vọng. Trên những chiếc bàn nhỏ, bạn có thể lấy nó ra.

Tôi ghét thực tế là chúng ta phải "thiết kế bảng của chúng tôi để tránh thay đổi chúng". Tôi chỉ không nghĩ rằng điều đó hoạt động trong thế giới trang web ngày nay. Bạn không thể đoán trước mọi người sẽ sử dụng phần mềm của bạn như thế nào, đó là lý do tại sao bạn nhanh chóng thay đổi mọi thứ dựa trên phản hồi của người dùng. Với mongodb, bạn có thể thêm "cột" theo ý muốn mà không cần thời gian chết. Bạn thậm chí không thực sự thêm chúng, bạn chỉ cần chèn dữ liệu với các cột mới và nó tự động thực hiện.

Đáng kiểm tra: www.mongodb.com


2
MySQL vẫn được sử dụng trong nhiều hệ thống, vì vậy câu hỏi thực sự là làm thế nào để đạt được sự thay đổi lược đồ trong SQL RDBMS, mặc dù tôi cũng là một người ủng hộ NoSQL nhiệt tình.
Alexy

1

Nói chung, câu trả lời sẽ là "Không". Bạn đang thay đổi cấu trúc của bảng có khả năng sẽ yêu cầu nhiều cập nhật "và tôi chắc chắn đồng ý với điều đó. Nếu bạn muốn làm điều này thường xuyên, thì tôi sẽ cung cấp một giải pháp thay thế cho các cột" dummy "- hãy sử dụng VIEWs của bảng để nhập SELECTdữ liệu. IIRC, việc thay đổi định nghĩa của một chế độ xem tương đối nhẹ và việc chuyển hướng qua một chế độ xem được thực hiện khi kế hoạch truy vấn được biên dịch. Chi phí là bạn sẽ phải thêm cột vào bảng mới và thực hiện xem JOINtrong cột.

Tất nhiên điều này chỉ hoạt động nếu bạn có thể sử dụng các khóa ngoại để thực hiện xếp tầng xóa và không. Phần thưởng khác là bạn có thể tạo một bảng mới chứa kết hợp dữ liệu và hướng chế độ xem đến nó mà không làm ảnh hưởng đến việc sử dụng của khách hàng.

Chỉ là một suy nghĩ.


1

Sự khác biệt giữa Postgres và MySQL về mặt này là trong Postgres, nó không tạo lại một bảng, nhưng sửa đổi từ điển dữ liệu tương tự như Oracle. Do đó, hoạt động diễn ra nhanh chóng, trong khi vẫn yêu cầu cấp phát một khóa bảng DDL độc quyền trong thời gian rất ngắn như những người khác đã nêu ở trên.

Trong MySQL, thao tác sẽ sao chép dữ liệu vào một bảng mới trong khi chặn các giao dịch, đây là vấn đề chính đối với các DBA MySQL trước phiên bản 5.6.

Tin tốt là kể từ khi phát hành MySQL 5.6, hạn chế gần như đã được dỡ bỏ và bây giờ bạn có thể tận hưởng sức mạnh thực sự của MYSQL DB.


3
Có vẻ như bạn đang cố gắng liên kết đến tham chiếu liên quan đến thay đổi trong MySql 5.6, nhưng nó không hoạt động. Vui lòng thử lại.
dg99

1

Như SeanDowney đã đề cập, pt-online-schema-changelà một trong những công cụ tốt nhất để thực hiện những gì bạn đã mô tả trong câu hỏi ở đây. Gần đây tôi đã thực hiện rất nhiều thay đổi giản đồ trên DB trực tiếp và nó diễn ra khá tốt. Bạn có thể đọc thêm về nó trên bài đăng trên blog của tôi tại đây: http://mrafayaleem.com/2016/02/08/live-mysql-schema-changes-with-percona/ .



0

Các cột giả là một ý tưởng hay nếu bạn có thể dự đoán loại của chúng (và làm cho chúng có thể vô hiệu). Kiểm tra cách bộ lưu trữ của bạn xử lý null.

MyISAM sẽ khóa mọi thứ nếu bạn thậm chí đề cập đến tên bàn khi đi qua, trên điện thoại, tại sân bay. Nó chỉ làm điều đó ...

Điều đó đang được nói, ổ khóa không thực sự là một vấn đề lớn; Miễn là bạn không cố gắng thêm giá trị mặc định cho cột mới vào mỗi hàng, nhưng hãy để nó ở trạng thái rỗng và công cụ lưu trữ của bạn đủ thông minh để không viết nó, bạn sẽ ổn với một khóa chỉ giữ đủ lâu để cập nhật siêu dữ liệu. Nếu bạn cố gắng viết một giá trị mới, tốt, bạn đang nâng cốc.


1
Tôi đã thử thêm một cột NULL vào bảng InnoDB và nó phải xây dựng lại toàn bộ bảng; không phải là hoạt động "cập nhật siêu dữ liệu" đơn giản.
Daniel

Tôi nghĩ rằng ý tưởng là bao gồm các cột bổ sung, có thể nullable, trong cơ sở dữ liệu khi nó được thiết kế, để nếu một tính năng mới được yêu cầu, người ta có thể "thêm" cột mới bằng cách bắt đầu sử dụng nó. Nó sẽ không có một cái tên đẹp, nhưng nếu loại dữ liệu được chọn / dự đoán chính xác thì nó sẽ hoạt động.
supercat

0

TokuDB có thể thêm / bớt cột và thêm chỉ mục "hot", bảng hoàn toàn có sẵn trong suốt quá trình. Nó có sẵn trên www.tokutek.com


-6

Không hẳn vậy.

Rốt cuộc, bạn đang thay đổi cấu trúc cơ bản của bảng và đó là một chút thông tin khá quan trọng đối với hệ thống cơ bản. Bạn cũng (có khả năng) đang di chuyển nhiều dữ liệu trên đĩa.

Nếu bạn định làm điều này nhiều, tốt hơn hết bạn chỉ cần đệm bảng bằng các cột "giả" có sẵn để sử dụng trong tương lai.


3
Độn bàn bằng các cột giả dường như là một ý tưởng thực sự tồi.
Jost
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.